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Preface 


A workshop  on  the  Satellite  Networks:  Architectures,  Applications,  and  Technologies,  hosted 
by  the  Space  Communication  Program  at  NASA  Lewis  Research  Center  in  Cleveland,  Ohio 
was  held  on  June  2-4,  1998  at  the  Sheraton  Airport  Hotel  in  Cleveland,  Ohio.  More  than  275 
representatives  of  industry,  academia  and  government  participated  in  the  workshop. 

We  decided  to  host  this  workshop  because  global  satellite  networks  are  moving  to  the  forefront 
in  enhancing  national  and  global  information  infrastructures — due  to  the  unique  networking 
characteristics  of  communication  satellites.  Simultaneously,  broadband  data  services  are 
emerging  as  the  major  market  driver  for  future  satellite  and  terrestrial  networks.  Convergence  of 
satellite  and  terrestrial  networks  is  widely  acknowledged  as  the  foundation  for  an  efficient  global 
information  infrastructure.  In  the  past  two  years,  various  task  forces  and  working  groups  around 
the  globe  have  identified  pivotal  topics  and  key  issues  to  address  if  we  are  to  realize  such 
networks  in  a timely  fashion.  In  response,  industry,  government,  and  academia  undertook  efforts 
to  address  these  topics  and  issues.  There  was  a need  to  assess  the  progress  made  to  date  and 
chart  the  future.  This  workshop  provided  a forum  to  assess  the  current  state-of-the-art,  identify 
key  issues,  and  highlight  the  emerging  trends  in  the  next-generation  architectures,  data  protocol 
development,  communication  interoperability,  and  applications. 

The  response  to  the  workshop  was  outstanding  and  the  results  are  shown  in  the  attached  papers. 
In  addition  to  several  panels,  workshop  sessions  covered  a wide  range  of  topics 

• Access  technology  and  protocols 

• Architectures  and  network  simulation 

• ATM  over  satellite  networks 

• Internet  over  satellite  networks 

• Interoperability  experiments  and  applications 

• Multicasting 

• NASA  interoperability  experiment  programs 

• NASA  mission  applications 

• TCP/IP  over  satellite:  issues,  relevance,  and  experience 

Contributions  to  this  workshop  are  highly  appreciated,  and  we  hope  to  build  on  its  success. 


Kul  Bhasin 
Workshop  Organizer 

Chief,  Satellite  Networks  and  Architectures  Branch 
NASA  Lewis  Research  Center 
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Tuesday,  June  2, 1998 

The  Internet:  Enhancing  the  Internet  for  Space  Today 

8:30  Welcoming  Remark:  Donald  J.  Campbell,  Director,  NASA  Lewis 

8:40  NASA/Industry  Programs:  A Response  to  the  Satellite  Industry  Task  Force 
Challenges  Ballrooms  A & B 

Chair:  James  Bagwell;  Manager;  Commercial  Communications  Program; 

NASA  Lewis 

Samuel  Venneri;  Chief  Technologist;  NAS  A Headquarters 

Thomas  Brackey;  Executive  Director  of  Technical  Operations;  Hughes  Space  & 

Communications 

Prakash  Chitre;  Vice  President  Technology;  COMSAT  Laboratories 
Ramon  DePaula;  Program  Executive,  Code  S;  NAS  A Headquarters 
Charlene  Gilbert;  SOMO  Technology  Manager;  NASA  Johnson 

Session  description:  This  session  will  address  the  ad  hoc  Satellite  Industry  Task  Force 
(SITF)  technical  challenges  and  NASA’s  response  to  them. 

The  ad  hoc  SITF  consisting  of  satellite  communications  industry  representatives, 
academia,  and  government  observers  came  together  in  late  1994  to  address  the  role  of 
satellites  in  the  emerging  national  and  global  information  infrastructure.  On  July  31, 
1996,  the  SITF  presented  its  findings  to  Daniel  Goldin,  NASA  Administrator;  Kaminski, 
then  Deputy  under  Secretary  for  Defense  for  acquisition;  high-ranking  government 
executives;  and  industry  executives. 

In  this  opening  session,  Samuel  Venneri,  NASA  Chief  Technologist,  and  other  NASA 
executives  will  outline  NASA’s  response  to  several  of  SITF’ s technical  findings. 
Thomas  Brackey,  Executive  Director  of  Technical  with  Hughes  Space  and 
Communications,  and  Prakash  Chitre,  Vice  President  of  Technology  with  COMSAT 
Laboratories,  will  provide  industry’s  perspective  on  these  interoperability  issues. 

10:20  Break 

10:35  Opening  the  Technical  Program:  Kul  Bhasin,  Chief,  Satellite  Networks  & 
Architectures  Branch;  NASA  Lewis 

10:40  Invited  Session:  Internet  over  Satellite  Networks 
Ballrooms  A & B 

Chair:  Frank  Gargione;  ACTS  Project  Manager;  Lockheed  Martin 
Dennis  Conti;  Vice  President;  Hughes  Networks  Systems 
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Burt  Liebowitz;  Chief  Technology  Officer;  Orion  Network  Systems 

“Providing  Internet  Access  to  ISP’s  Using  Geosynchronous  Satellites  - A Case  History 

Based  on  Orion’s  Worldcast  Services” 

John  Baras;  Director;  Center  for  Satellite  and  Hybrid  Networks;  University  of  Maryland 
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“Internet  Protocols  over  ACTS  at  622  Mbps:  Implications  for  Future  Advanced  Internet 
Services” 
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Jim  Griner,  Paul  Mallasch,  Mark  Allman,  and  David  Stewart;  NASA  Lewis 

12:10  Lunch 

1:30  Plenary  Session:  TCP  over  Satellite:  Issues,  Relevance,  and  Experience 
Ballrooms  A & B 

Moderator:  Aaron  Falk;  Network  Systems  Engineer;  TRW  Space  & Electronics 

Keynote: 

Craig  Partridge 

Principal  Scientist;  BBN  Technologies 
“Does  TCP  Work  over  Satellite  Links  or  Not?” 

Norman  Butts;  Manager;  Systems  Engineering;  Telecommunications  Interactive 
Technology  Center;  Lockheed  Martin 

Eric  Travis;  Systems  Engineer;  Jet  Propulsion  Laboratory 

Lori  Jeromin;  Member  of  Technical  Staff;  MIT/Lincoln  Laboratory 

Victor  Barajas;  Member  of  Technical  Staff;  Hughes  Spaceway 

Session  description:  providing  Internet  service  over  satellite  depends  largely  on 
providing  good  Transmission  Control  Protocol  (TCP)  performance.  This  panel  will 
discuss  the  issues  with  today’s  TCP;  solved  and  unsolved  problems;  the  relevance  to 
commercial;  NASA,  and  military  applications;  and  approaches  to  dealing  with  or 
avoiding  TCP  problems.  Craig  Partridge  will  provide  an  overview  presentation  on  TCP 
performance  over  satellite.  The  remaining  panel  members  will  each  provide  brief 
presentations  (about  5 minutes)  on  specific  topics  of  their  choosing.  Following  the 
presentations;  there  will  be  an  open  question-and-answer  period. 

3:00  Break 
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Chair:  Pete  Vrotsos;  Chief,  Space  Communications  Office;  NASA  Lewis 

Keynote: 

A1  MacRae 

Senior  Research  Scientist,  Institute  for  Applied  Space  Research;  George  Washington 
University;  formerly  Director,  Satellite  Communications;  AT&T  Bell  Labs 
“Interoperability  - What  Is  It  and  Why  Is  It  So  Important?” 

Robert  Bauer;  ACTS  Project  Manager;  NASA  Lewis 

“New  Opportunities  with  the  Advanced  Communications  Technology  Satellite  (ACTS)” 

Richard  desJardins  and  Kenneth  Freeman;  Networking  Consultants,  Next  Generation 
Internet  Project;  NASA  Ames 

“NASA/NREN  Next  Generation  Internet  (NGI)  Activities” 

Ramon  DePaula;  Program  Executive,  Code  S;  NASA  Headquarters 
“Overview  of  G8  Global  Interoperability  for  Broadband  Networks  (GIBN)  Project” 

10:00  Break 

10:30  Plenary  Session:  Addressing  Interoperability 
Ballrooms  A & B 

Moderator:  Burt  Edelson;  Director,  Institute  for  Applied  Space  Research; 

George  Washington  University 

Keynote: 

Raj  Jain 

Professor  of  Computer  and  Information  Sciences 
Ohio  State  University 

“Addressing  Interoperability:  Issues  and  Challenges” 

Charlene  Gilbert;  SOMO  Technology  Manager;  NASA  Johnson 
Mark  Plecity;  New  Business  Development;  Iridium 
Sastri  Kota;  Technical  Consultant;  Astrolink 

Jim  Justiss;  Director  of  Systems  Engineering;  Hughes  Space  and  Communications 

Session  description:  achieving  interoperability  among  satellite,  terrestrial,  and  cellular 
network  systems  is  the  key  to  providing  a seamless  global  information  infrastructure. 
This  panel  will  discuss  the  operational,  standards,  market,  and  technical  barriers  that  are 
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being  addressed  by  industry,  government,  and  academia  for  the  purpose  of  achieving 
interoperability. 


Session  4 - Ballroom  A 
ATM  over  Satellite 
Networks 

Chair:  Tom  vonDeak;  Team 
Leader,  Satellite  Networks  & 
Architectures  Branch;  NASA 
Lewis 

Enrique  Cuevas 
AT&T 

“Overview  of  ATM 
Performance  and  QoS 
Requirements  for  Satellite 
Systems” 

Simon  Nawrot 
AT&T 

“ATM  over  Terrestrial/Satellite 
Network  - CTD  & CVD  QoS 
Laboratory  Measurements” 


William  Ivancic 
NASA  Lewis 

“Satellite/Terrestrial  Networks: 
End-to-End  Communication 
Interoperability  QoS 
Experiments” 

Yung  Ho 
Yurie  Systems 
“Efficient  and  Flexible  Link 
Enhancement  Techniques  for 
Wireless  ATM” 


12:00  Lunch 

1:30  Session  Breakout 


Session  5 - Ballroom  B 
Multicasting 


Chair:  Paul  Mallasch; 
Computer  Engineer,  Satellite 
Networks  & Architectures 
Branch;  NASA  Lewis 

Keynote: 

Kenneth  Miller 
Starburst  Communications 
“Reliable  Multicasting  over 
Satellite:  Issues  & 
Applications” 

Antoine  Clerget 
INRIA  U.R.  (France) 
“Organizing  Data 
Transmission  for  Reliable 
Multicast  over  Satellite 
Links” 

Doug  Dillon 

Hughes  Network  Systems 
“Satellite-Multicast 
Enhanced  Consumer  Internet 
Services” 


Yongguang  Zhang 
Hughes  Research  Labs 
“Integrating  Satellite 
Networks  with  Internet 
Multicast  Backbone 
(Mbone)” 


Daniel  Friedman 
University  of  Maryland 
“Error  Control  for  Satellite 
Multicasting” 
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Session  6 - O’Hare  Room 
Interoperability  Experi- 
ments and  Applications 

Chair:  Richard  Gedney; 
President,  Advanced 
Communication  Technology 


Mehran  Shariatmadar 
SpaceBridge 

“Applying  Heritage  Inter- 
Networking  Solutions  to  ATM 
Satellite  Systems” 


Thomas  Stephenson 
Milstar,  USAF 
“ATM  over  Satellite  for  the 
Warfighter” 


Dan  Daly 
Bellcore 

“ATM  Traffic  Measurements 
over  the  ACTS.  OC-12c  HDR 
Channel  with  a Distributed  Test 
System” 

Patrick  Gary 
NASA  Goddard 
“Testbed  for  Satellite  and 
Terrestrial  Interoperability 
(TSTI)  - A FY98  Program 
Product  of  632-50-50 
Communications  - Terrestrial” 

Dan  Shell 
CISCO 

“Satellite  Interoperability” 


3:00  Break 


Session  7 - Ballroom  A 
ATM  over  Satellite 
Network  Quality  of 
Service 

Chair:  Will  Ivancic;  Team 
Leader,  Satellite  Networks  & 
Architectures  Branch;  NASA 
Lewis 

Keynote: 

Louis  Dellaverson 
Motorola  Radio  Research 
Lab 

“Mobile  ATM  Networking” 

Rohit  Goyal 
Ohio  State  University 
“Traffic  Management  for 
Satellite-ATM  Networks” 


Prakash  Chitre 
COMSAT  Laboratories 
“ATM  via  Satellite:  Link  and 
Networking  Technologies” 


Sastri  Kota 
Astrolink 

“Satellite  ATM  Networks: 
Architectural  Issues  and 
Challenges” 

Pong  Chu 

Cleveland  State  University 
“FPGA  Based  Reconfigurable 
ATM  Switch  Testbed” 


3:30  Session  Breakout 


Session  8 - Ballroom  B 
Access  Technology  and 
Protocols 

Chair:  BenPontano; 
President,  COMSAT 
Laboratories 


Gony  Fairhurst 
University  of  Aberdeen 
“Integrated  Packet/Modem 
Processing  for  Transportable 
Terminals” 

Bill  Shvodian 
Lockheed  Martin 
“Multiple  Priority  Distributed 
Round  Robin  - ATM  Satellite 
MAC  Protocol” 

Leandros  Tassiulas 
University  of  Maryland 
“Broadcast  Delivery  with 
Limited  Feedback” 


John  Baras 

University  of  Maryland 
“Flow  Control  and  Dynamic 
Bandwidth  Allocation  in  DBS- 
Based  Internet” 


Session  9 - O’Hare  Room 
TCP/LP  over  Satellites 


Chair:  Patrick  Gary; 
Network  Project  Leader; 
NASA  Goddard 


Jeff  Semke 

Pittsburgh  Supercomputer 
Center 

“Automatic  TCP  Buffer  Tuning” 


Keith  Scott 

Jet  Propulsion  Laboratory 
“Improving  TCP  Performance 
over  Mobile  Satellite  Channels: 
The  ACKPrime  Approach” 

Tom  Henderson 
University  of  California, 
Berkeley 

“Transport  Protocols  for  IP  - 
Compatible  Satellite  Networks” 

James  Stepanek 
The  Aerospace  Corporation 
“Internet  Services  over  a Direct 
Broadcast  Satellite  Network: 
Challenges  and  Opportunities” 

DC  Palter 
Mentat 

“Improved  Satellite  Networking 
Using  the  Mentat  SkyXpress 
Protocol” 
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Thursday,  June  4, 1998 
Next-Generation  Space-Based  Architectures 

8:30  Visionary  Session  - Architectures,  Applications,  and  Technologies 
Ballrooms  A & B 

Moderator:  Kul  Bhasin;  Chief,  Satellite  Networks  & Architectures  Branch;  NASA 
Lewis 

Edward  W.  Ashford;  Vice  President,  Broadcast  Satellites;  Lockheed  Martin 

James  Bagwell;  Manager,  Commercial  Communications  Program;  NASA  Lewis 

William  Bailey;  Manager,  New  Markets  and  Technology;  CISCO 

John  Baras;  Director,  Center  for  Satellite  and  Hybrid  Networks;  University  of  Maryland 

Joe  Bravman;  Senior  Vice  President,  Corporate  Development;  Orbital  Science 

Steve  Goldstein;  Program  Director;  National  Science  Foundation 

Marie-Jose  Montepit;  Network  Design  Team;  Teledesic 

Session  description:  Looking  back  20  years  at  the  satellite  and  telecommunication 
industries,  it  is  hard  to  comprehend  the  vast  changes  that  have  occurred.  Just  five  years 
ago,  the  Internet  was  unknown  to  the  general  public.  What  will  the  next  20  years  bring? 
Who  will  be  the  users,  and  what  will  their  requirements  be?  What  are  the  next-generation 
architectures  (post-2005)  to  meet  the  users’  requirements?  What  are  the  technology 
trends  to  be  able  to  implement  the  future  architectures?  This  session  will  attempt  to 
answer  some  of  these  questions.  Panel  members  will  provide  their  vision  of  the 
applications  and  architectures,  including  technical  issues  that  must  be  resolved  for 
satellites  to  be  the  integral  element  of  the  21st  century  telecommunication  infrastructure. 

10:30  Break 


11:00  Open  Forum:  Next  Step 
Ballrooms  A & B 

Moderator:  Thomas  Brackey;  Chair,  Telecommunications  Industry  Association, 
Satellite  Communication  Division 

Session  description:  Broadband  data  services  are  emerging  as  the  major  market  driver 
for  future  satellite  and  terrestrial  networks.  The  convergence  of  satellite  and  terrestrial 
networks  is  widely  acknowledged  as  the  foundation  for  an  efficient  global  information 
infrastructure.  Various  working  groups  have  identified  pivotal  topics  and  key  issues  to  be 
addressed  for  the  realization  of  such  networks  in  a timely  fashion.  In  response,  efforts 
have  been  undertaken  by  industry,  government,  and  academia  in  addressing  these  topics 
and  issues.  This  workshop  has  provided  the  forum  to  assess  the  current  state-of-the-art, 
identify  key  issues,  and  highlight  the  emerging  trends  in  the  next-generation  architec- 
tures, data  protocol  development,  communication  interoperabilty,  and  applications. 
Thomas  Brackey  will  lead  the  session  attendees  in  discussing  and  summarizing  the  issues 
that  should  be  addressed  to  further  realize  the  goal  of  interoperable  satellite  networks. 

The  output  of  this  discussion  process  will  be  used  in  the  planning  processes. 
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Opening  Session 

NASA/Industry  Programs: 

A Response  to  the  Satellite 
Industry  Task  Force  Challenges 


Page  intentionally  left  blank 


§1:  COMSAT 

Vi'  LABORATORIES 


Satellite  Communications 
and 

Interoperability 


Prakash  Chitre 
COMSAT  Labs 
Clarksburg,  MD  20871 
Tel:  301  428-4167 
Fax:  301  428  7747 

e mail:  prakash.chitre@comsat.com 
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COMSAT 


LABORATORIES 


Satellite  Communications  and 
Interoperability 


• Interoperability 

- Terrestrial  and  Satellite  Network  Integration 

- Common  Air  interface  Specifications  for  Satellite  Networks 

• Challenges 

• Current  Solutions 

• Future  Prospects 
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m COMSAT 

VS?  LABORATORIES 


Seamless  Integration  of 
Satellite  and  Terrestrial  Networks 

• Satellite  Link  Transparent  to  the  End  User 

• Service  Provisioning  in  a Cost-Efficient  Manner 
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COMSAT 


LABORATORIES 


Steps  for  Achieving  Interoperability 

• Modify  Existing  Telecommunications  Standards 

• Develop  New  Standards 

• Design  and  Implement  Satellite  Interface  Products 

• Develop  Next  Generation  Satellite  Networks 

• Conduct  Tests  and  Demonstrations 
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COMSAT 


LABORATORIES 


Communications  and 
Interoperability  Section  and  TR-34.1 


• Wireless  ATM 

• ATM  Traffic  Management 

• ATM  Speech 

• ATM  QOS 

• Internet  Over  Satellite 

• Common  Air  Interfaces  for  Satellite  Systems 

• Interoperability  Reference  Models 


COMSAT 

LABORATORIES 


Communications  and  Interoperability 
Section/TR-34.1 

Major  Accomplishments 

• Established  a liaison  with  ATM  Forum  Wireless  ATM  Group  for  the 
joint  development  of  satellite  ATM  network  architectures,  protocols, 
mobility  standards 

• Worked  closely  with  Internet  Engineering  Task  Force  (IETF)  for  internet 
protocols  to  work  well  over  satellite 

- TCPSAT  Group  has  been  established 

• ATM  Traffic  Management  (TM  4.0) 

- Modifications  to  accommodate  satellite  delay  were  approved  by  ATM  Forum 

• ATM  Speech 

- Worked  with  ATM  Forum  to  develop  ATM  speech  standards  to  be 
bandwidth  efficient 

• Common  Air  Interface  for  Satellite  Systems 

- Standardize  Common  Air  Interfaces  for  a range  of  satellite  systems  from 
satellite  personal  communications  systems  to  broadband  satellite  systems 

• Letter  Ballots  on  ATM  Networks  and  GMPCS 
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© COMSAT 


LABORATORIES 


Common  Air  Interfaces  for 
Satellite  Systems 


• GMPCS 

- Letter  Ballot:  “High  Level  Requirements  for  Common  Air 
Interface  for  GEO  Mobile  (Super-GEO)  Satellite 
Communications  Featuring  Dual  Mode  Operation  with 
Terrestrial  GSM” 

• Satellite  Link  Protocol 

- Requirements  for  the  Common  Air  interface  for  ATM  Over 
Satellite  Links 


COMSAT 

LABORATORIES 


Current  Solutions 


• ATM  Standards 

- Some  Evolving  to  be  Satellite  Compatible 

• ATM  Satellite  Link  and  Networking 
Proprietary  Products  for  High  Quality,  Cost 
Efficient  Operation 

• Internet  Standards 

- A number  of  TCP  Optional  Implementation  for  Better 
Performance  Over  Satellite 

• Satellite  Internet  Products  with  Proprietary 
Solutions 
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A7R0  designed  for  high  spead  mufti-media  traffic 
A™  networks  aspect  fiber-like  quality  from  satellite  link 


COMSAT 

LABORATORIES 


Future  Prospects 


• Common  Air  Interface  Specifications  for 

- GEO  Mobile  with  Dual  Mode  Operations  with  Terrestrial 
GSM 

- ATM  Over  Satellite  Links 

- TCP/IP  Over  Satellite  Links 

• UMTS  Compatible  Satellite  Common  Air 
Interface  Protocol 

• Satellite  Network  Protocols  for  Ka-band 
Systems 
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Space  Operations  Management  Office 
National  Aeronautics  and  Space  Administration 


NASA’s  Plan 

Reality  - NASA’s  budget  is  flat 

The  prospect  of  getting  additional  funds  from  Congress  for  new  program 
starts  is  faint 

Where  will  the  money  come  from$? 

The  Game  Plan 

- Change  strategy  in  the  relationship  of  technology  and  missions 

- Technology  enables  the  missions 

- One  Galileo  mission  vs  12  small  planetary  missions  - $1.9 
Billion  dollars 

- Integrate  technology  across  the  Agency 

- Consolidate  the  management  of  space  operations 

- Implement  strategies  to  reduce  the  cost  of  operations 

- NASA  spends  more  than  $4  Billion/year  on  operations 

- Outsource,  privatize,  commercialize 


- Redirect  the  cost  savings  to  exploration  and  new  program  starts 


Space  Operations  Management  Office 
National  Aeronautics  and  Space  Administration 


Space  Operations 


Space  Operations  Management  Office  (SOMO)  is  an  agency-wide  provider  of 
mission  and  data  services.  Includes  the  expertise  and  systems  necessary  to 
support  the  mission  preparation  and  flight  execution  phases  of  a program  or  project. 


Mission:  Implement  Agency  space  operations  goals  while  successfully 
providing  services  which  enable  Enterprise  mission  execution 


Goal  1:  Meet  the  strategic  mission  needs  of  the  NASA  Enterprises  while  reducing 
operations  costs,  consolidating  and  integrating  operations  across  the  Agency, 
emphasizing  the  use  of  technology,  and  increasing  standardization  and  interoperability 

Goal  2:  Transition  the  civil  service  and  Jet  Propulsion  laboratory  (JPL)/Cal  Tech  work  force 
from  routine,  day-to-day  operations  to  science,  research,  and  development,  except  for  core 
competencies 

Goal  3:  Transition  all  operations  contracts  for  products  and  sen/ices  to  performance-based 
contracting 

Goal  4:  Transition  operations  functions  that  generate  products  and  services  to  outsourcing, 
privatization,  and,  ultimately,  commercialized  sendees 

Goal  S:  Restructure  management  and  operational  processes  using  the  concept  of 
customer/service  provider 
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Invited  Session 

Internet  over  Satellite  Networks 
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Summary  Comments 


HUGHES 

NETWORK  SYSTEMS 


A HUGHES  ELECTRONICS  CO*  IF  ANY 


• The  LEO/MEO/GEO  wars  will  only  increase 
the  FUD  factor  (fear,  uncertainty,  and  doubt) 
among  potential  satellite  network  buyers 


• It  is  in  the  interests  of  a]}  such  systems  to 
foster  standards  efforts  that: 

- allow  TCP  to  operate  better  with  higher  latency 
and  jitter 

- result  in  more  efficient  browser  implementations 

- support  security  standards  at  levels  above  IP 

- advance  quality  of  service  (QoS)  standards 
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II IBCII  UMIIS 


Providing  Internet  Access  to  ISPs 
using  Geosynchronous  Satellites 

A Case  History  Based  on  Loral  Orion’s  WorldCast®  Service 


Presented  to  Satellite  Networks: 
Architectures,  Applications  and 
Technologies  Workshop 

June  2, 1998 

Cleveland,  OH 


Rockville,  IHD 


ORi^rsi 

KIM  II  1TJIIM 


The  Internet  Market 


• Customers 

- End  Users  in  the  Home 

- Internet  Service  Providers  (ISPs) 

- Corporations  (Multi-user  Enterprises) 

• Services 

- File  Transfers 

- Mail 

- Web  Search 

- Multicast 

- Etc. 

5/27/98  ||g:Geo6298.ppt 
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ORi^rsi 

alters  si  itihsij 


Role  of  Geosynchronous  Satellites 
in  Internet/Intranet 


• Economic  Provision  of  Services  to  Customer  Base, 
especially  where: 

- There  is  no  terrestrial  infrastructure 

- There  is  an  asymmetric  traffic  flow 

- Terrestrial  lines/services  are  congested 

- >64  Kbps  is  expensive  terrestrially 

- Broadcast/multicast  services  are  prevalent 

• Satellites  can  be  used  for: 

- Backbone 

- Trunking  to  POP  from  Internet  NAP 

- Direct  delivery  to  customer  premise 

5/27/98  Up:Geo6298.ppl  .1 
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An  Example:  Loral  Orion’s 
WorldCast  Service  for  ISPs 


• Large  Earth  Station  Uplink  in  US  to  Europe,  then  Asia 
and  Latin  America 

• Low  Cost  Access  to  US  Internet 

• Asymmetric  Data  Transfer 

- High  bandwidth  to  Europe 

- Low  bandwidth  for  request  and  ACKs  (via  satellite  or 
terrestrial  link) 

• Broadcast/Multicast  Services 

• Quality  of  Service  Guarantees  designed  primarily  for 
Overseas  ISPs  and  ISP-like  Enterprises 

- Uses  frame  relay  CIR  concept  to  insure  bandwidth 

5/27/98  llg:(i«*29R.ppi  4 
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Orion  1 - Now 
Orion  2 - Early  99 
Orion  3 - Late  98 


ogj^rsj  Orion’s  Coverage  Map 


2S^  WorldCast  - US  to  Europe 


Single  carrier  example  of  Orion’s  WorldCast  System.  Packets  arc  transmitted  from  the  Orion  hub  to  two 
European  ISPs.  ISP  A has  2 POPs,  one  of  which  has  a satellite  request.  ISP  B has  2 POPs  and  uses  a 
terrestrial  request.  In  this  example.  Packet  “n”  is  transmitted  from  the  US  Internet  to  all  sites.  Only  ISP  A’s 
POP  I accepts  the  packet. 


Packet 


Local 


Packet  “si” 
(Response) 


Request 

packet 


International  Fiber 

Could  be  ISP’s  or 
Kia  relationships 
with  higher  tier  ISP 


Local 

ISP  A 

— 

Loop 

, POP  1 

-Q 

ISP  A 

— 

Local 

pop; 

" Loop 

n 

•9 

ISP  B 

, — 

Local 

POP  I 

‘ 

Loop 

“■9 

ISP  B 



Local 

POP  2 

Loop 

Packet  “n 


Request 

packet 


Europe 
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ORIGIN! 

StlSltl  Sr«lf«S' 


WorldCast  ISP 
Routing/Hybrid  System 


satellite 


5/27/98  Hg:Cico6298.ppt 


ORi3rsi  Geosynchronous  Satellite  Versus 

Terrestrial  or  LEO 


» Pro-GEO  Satellite 

- Efficient  for  broadcast/multicast 

- Can  access  remote  locations 

- More  bandwidth  in  some  locations 

- Statistical  multiplexing  for  wide 
area  aggregation 

- Amenable  to  asymmetric  data 
transfer  (to  match  traffic  flow) 

- Can  bypass  congestion  points 

- Bypass  expensive  national  back 
hauls 

5/27/98  Hg:Geo6298.ppt 


• Con-GEO  Satellite 

- For  some  applications,  impact 
of  satellite  delay  on  TCP/IP 
can  limit  throughput  of  file 
transfers  and  increase 
response  time  for  Web  page 
retrievals 

- Unicast  could  be  more 
expensive  in  highly  developed 
countries 
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Concerns  When  We 
Announced  Service 


ORI 


3n 


• Customer 

- Throughput  degradation  because  of  satellite  delay 

- Impact  of  bit  error  rate  on  satellite  link  “goodput” 

- Ability  to  fill  a channel  with  multiple  simultaneous 
file  transfers 

• Loral  Orion 

- Surge  impact  for  overbooked  ISPs 

- Security  Issues 


5/27/98  Hg:Geo6298.pp<  9 

Outcome 


• Customer  Concerns 

- No  problem  regarding  throughput 

. Most  ISP  customers  limited  by  local  modem  or  ISDN  line 

- Bit  error  rate  not  an  issue 

• We  design  at  BER  <1  xlO"7  for  either  99%  or  99.5% 
availability  (use  Reed-Solomon) 

- Channels  can  be  filled 

• Loral  Orion  Concerns 

- Surges  limited  because  most  customers  do  not  order 
EIR 

- Security  not  an  issue  in  ISP  world 


5/27/98  llg.Geo6298.prl 
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Future:  Expansion  to  Corporations 
for  Inter  and  Intranet  (direct  to  roof-top) 


• Move  to  DVB/MPEG  technology  for 

- Security 

- Controlled  access  to  services 

- Broader  range  of  CIRs 

- Lower  cost  VSAT 

- Saturated  transponder  operation  (up  to  54  mbps  per  carrier) 

- Video,  voice  and  data  service  on  same  carrier 

• Caching 

• Performance  Enhancement  for  higher  end  to  end  throughput 
because  Corporation  is  no  longer  modem  limited 

- Spoofing 

- Proxy  server 

- IP  enhancements 

- Caching 

5/27/98  Hg:Geo6298.pp»  || 


ORI 


Summary 


• Geosynchronous  satellites  are  extending  the  reach  of 
Internet 

• Could  be  a performance  hit,  but  will  not  be  noticed  by 
most  customers  and  will  not  affect  ISP’s  ability  to  fully 
utilize  satellite  channels 

• Performance  enhancements  are  (or  soon  will  be) 
available  for  customers  who  need  high  data  rates,  and 
low  response  times 

• GEO  satellites  are  uniquely  capable  of  providing 
multicast  applications 

• GEOs  can  overcome  “last  mile”  problem,  especially  in 
emerging  countries 


5/27/98  Hg:Geo6298.ppt 
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Total  Network  Capacity  Demand  { 


CSHGfj 


for  Broadband  Internet  Services 

John  S.  Baras 

Center  for  Satellite  and  Hybrid  Communication  Networks 
University  of  Maryland  College  Park 

Satellite  Networks:  Architectures,  Applications  and  Technologies 
NASA  Lewis  Research  Center 
June  2, 1998 
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New  Business  Paradigm 


Host-centric  Data 


* The  “New  Data”:  Internet  / Intranet  / Extranet 
applications 

Digital,  compressed  voice,  audio  and  video 


• Paradigm  shifts: 

- Data  applications 
require  flexible 
connectivity 

- Applications 
require  much  larger 
capacities  and 
“bandwidth-on- 
demand” 

- Subscribers  require 
low-cost,  high 
capacity  access 

- Enterprise  networks 
require  in  addition 
scalability  .dependable 
performance,  simple 
network  management, 
controlled  costs 
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The  “Last  Mile”  is  Key 


• Local  Access  options  : 

- Fiber  to  anywhere  (FTTN,  FTTC,  FTTH,  SDV) 

- Copper  twisted  pair  wire  (ADSL,  VDSL, . . . HDSL) 

- Cable  Television  (CATV),  coaxial  cable  (HFC) 

- Multichannel  Multipoint  Distribution  Service  (MMDS) 

- Local  Multipoint  Distribution  Service  (LMDS) 

- Broadband  Satellites 

• Not  a technology  issue 

• Economic  and  marketing  issue 

• Time  of  deployment  & market  penetration 
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Broadband  Wireless  Infrastructures: 
Satellite  Constellations 


• DBS  major  success 

• New  remarkable  satellite  constellations 

• FSS  or  Mobile,  LEO  or  MEO 

• From  8kbps  to  1 Gbps  and  higher;  on  demand 

• Competition  to  fiber  (“faster  than  light”) 

• On-board  processing,  spot  beams,  hoping  beams,  autonomy 

• Globalstar,  Iridium,  Teledesic,  Spaceway,  CyberStar, 
PanAmSat,  Astrolink, ... 

• Newest  EHF  satellites:  Celestri,  OrbLink,  Lockheed  Martin, 
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just  a Bandwidth  Issue 


• Challenge:  Exponential  growth  in  demand  workloads  cannot  be 
met  by  traditional  data  services  with  scalability  groth  linear  in 
network  bandwidth  and  server  capacity 

• Traditional  unicast  (poin-to-point)  connection-oriented  data 
services  uneconomical  and  wasteful 

• Utilize  distributed  caching,  smart  prefetching,  dynamic 
bandwidth  allocation,  reliable  multicast,  adaptive  hybrid  data 
delivery 

• Need  to  broadacst  the  right  set  of  data:  highly  in  demand 

• Balance  data  delivery  modes  to  match  user’s  request 

• Broadcast  the  right  amount  of  the  hottest  data  and  provide  the  rest  on  demand 


“Push”  Information  Distribution 


DshcN 


• Why  important? 

• Audio/video  streaming,  software  distribution,  message 
distribution 

• Give  listeners  up-to-date  -ness  guarantee 

• Get  network  economies  of  scale  and  efficiency 

• Event  driven  enterprises 

• Individualized  content  need  not  require  per-user  data 
streams:  filtering  at  the  desktop,  integration  at  the  desktop 

• “Push”  spending:  1996  $ 8 B,  2002  $ 19  B 


• “Push”  needs  multicast : Intranet  and  Internet  multicast 
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Distributed  Multi-Tier 
Database  Architecture 


: 


TDPPlOBy 

wriaipieaeM 


WtasteMLAN 


Network  Operations  Center  (NOC) 
for  Hybrid  Internet  Service 


• HGW  : first  NOC  object  that  receives  data  ( Router) 

- HGW  prioritizes  Hybrid  Internet  traffic 

• SGW  jobs:  mixture  of  Internet  and  exogenous  traffic 

- Exogenous  traffic:  package  delivery  and  data  feed  traffic 

- SGW  maintains  four  queues  : two  for  package  delivery  and  data  feed 

two  for  the  two  priority  levels  of  Internet 

• Exogenous  traffic  high  priority  : fluctuations 

in  bandwidth  allocated  to  Hybrid  Internet 

• Self-similar  traffic:  Interactive  users  as  ON-OFF  processes 
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NOC: 

Bandwidth  Allocation  Strategies 


Comparison  of  Bandwidth  allocation  strategies 


Buffer  per  Connection 

500  packets 

Total  Bandwidth 

15  packets/unit  time 

Number  of  Connections 

5 connections 

Constant  Arrival  Rate 

10  packets/unit  time 

Mean  of  the  Uniform  Arrival  Rate 

5 packets/unit  time 

Delay  Imposed  to  Queued  Packets 

0.1  unit  time 

Connl: 

1.4469 

1.4468 

0.0 

Conn2: 

2.0720 

2.0720 

0.5298 

Conn3: 

1.6941 

1.6689 

0.204 

Conn4: 

2.0541 

2.0524 

0.0741 

Conn5: 

1.7182 

1.7088 

0.8847 

EB 

wrm 

MDQSF 

Common  Input  Data 


Average  Delays 


All  strategies:  controller  knows  (per  connection)  queue  status 
Three  strategies  investigated: 

• Equal  Bandwidth  allocation  (EB) 

• Fair  Bandwidth  allocation  (FB) 

• Most  Delayed  Queue  Served  First  Bandwidth  allocation  (MDQSF 
MDQSF  is  best 


DBS-based  Internet  Access: 
IP  Multicast  and  Enhancements 


• Two  IETF  WGs:  TCP  over  Satellite  and 
Unidirectional  Internet  routing 

• Intelligent  asymmetric  data  transmission 

• Two  types  of  traffic  (depending  on  threshold  T bps): 

- Low  data-rate  (or  “short  length”)  via  terrestrial 

- High  data-rate  (or  “bulky”)  via  satellite 

• Terrestrial  LAN  extension  of  DBS-based  Internet 

• Distribute  DBS  services  from  a single  receiver  out  to  multiple 
users,  thus  reducing  cost 

• Satellite  hybrid  hosts  can  redistribute  data  to  mobile  users 

• “Local  loop”  anything:  Ethernet,  ATM,  cable  TV,  wireless 
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Response  Tune 


II 


ata  Delive 


• Objective:  deliver  needed  data  with  minimum  delay  to  very 
large  numbers  of  users 

• Pure  data  broadcast  (“push”): 

- Passive  users;  Accessed  concurrently  by  any  number  of  users 

- Limitation:  users  wait  for  data  of  interest  to  appear 

- Access  latency  depends  on  volume  of  broadcast  data 

• Pure  unicast  (“pull”): 

- Active  users;  Cannot  scale  beyond  capacity  of  server  and  network 

- Access  latency  depends  on  aggregate  workload  and  network  load 

• Ammar  and  Wong  (1985),  Wong  (1988);  teletext,  videotex 
Gifford  (1985, 1990);  community  information  services  (Boston) 

Imielinski  and  Badrinath  (1994),  Franklin  and  Zdonik  (1996);  wireless  communications 
and  mobile  computing 


Hybrid  Data  Delivery  Model 


Number  of  Broadcast  Items 


• DB  contains  N items 
of  equal  size  S 

• Demand  for  fh  item  : 

Poisson ; rate  A* 
A^  > A 2 ^ • • . > Aj^ 

• Server  M/M/1;  mean 

service  time  = 1/p 

• Server  can  broadcast  at 

rate  B 


• Broadcast  n first  items  ; On-demand  N-n  items;  Ak=  S,k  Aj 

• Expected  response  time  for  requests:  l/(n-(AN-A„)) ; 7^,=  nS/2B 

• Expected  response  time  for  hybrid : weighted  average  of  Tpull  and  Tpush 
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Response  Time 


Adaptive  Repetitive  Data  Broadcast 


pjpsfin: 


>8^29! 


Size  and  content  of  broadcast 
continuously  updated;  Not  fixed 
schedule 

Queue  storing  vapor  data:  V 

Item  broadcast  appended  to  tail  of 
V and  its  temperature  reduced  by 
Coolins  Factor 


Contents  of  V modified  every  cycle 
defined  by  a placeholder 

Notification  on  to-be  broadcast 
items  by  broadcasting  index: 


Two-Phase  Algorithm  to 
Update  Broadcast  Queue  Contents 


A«a  ^ ^ ^ Ap  Ag  Ap  ^ ^ Aq  ^ Ag 

Vapor : A,  B,  C,  D,  E,  F,  G ; Liquid:  H,  I 


• Sort  items  by  then- 

temperature 

• Demote  to  liquid  all 
vapor  data  with 
temperature  < hottest 

liquid  item 

• Marginal  gains : 

(2a)  Demote  vapor  items  in 
increasing  order  of 
temperat.  while  6>60 

(2b)  Promote  liquid  items  in 
decreasing  order  of 
temperat.  while  6 <60 
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Simulation  Experiments 


• Parameters: 

- Broadcast  and  down  link  rates:  12  Mbps 

- Uplink  rate:  28.8  kbps 

- DB  has  10,000  items,  each  50  kB  in  size 

- System’s  pull  capacity  //  : 30  items/sec 

- Vary  workload  from  light  ( RR  < fi ) to  heavy  ( RR  = 100  ji) 

• Response  time  depends  only  on  hot-spot  size  (100  items) 

(not  on  workload  intensity 

• Scalability  increased  by  two  orders  of  magnitude 
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Exi 
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On  confre 


TCP/IP 


structures,  lira 
srling  Software 


^ — 630-665-1396 
drbeering@sprynet.com 


What  is  118x? 


1 1 8x  is  the  latest  in  a series  of  “1 1 8”  experiments, 
designed  to  study  the  optimization  of  TCP/IP  and 
ATM  protocols  over  geostationary  distances  across 
multiple  operating  environments  using  NASA’s 
Advanced  Communications  Technology  Satellite 
(ACTS) 

Experiment  1 18j  ran  from  August  to  November,  1997 
using  and  focused  on  Sun’s  Solaris  2.6  TCP/IP 
implementation 

Experiment  118x  operates  during  May-September, 
1998 

The  satellite  link  operates  at  622  Mbps  (OC-12c) 
between  Livermore,  CA  and  Cleveland,  OH 
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To  develop  a recognized,  interoperable,  high- 
performance  TCP/IP  implementation  across 
multiple  operating  platforms  working  in 
partnership  with  the  computer  industry 

To  work  with  the  satellite  industry  to  answer 
outstanding  questions  regarding  the  use  of 
standards  (TCP/IP  and  ATM)  for  the  delivery 
of  advanced  data  services,  and  for  use  in 
spacecraft  architectures 


1 1 8x  Experiment  Participants 

Government  Laboratories 

NASA  Lewis  Research  Center 
NASA  Johnson  Space  Center  (SOMO) 
NASA  Jet  Propulsion  Laboratory 

Lawrence  Livermore  National  Laboratory 
NTONC  Lead 

Naval  Research  Laboratory 
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Communications  Industry 


Ampex  Data  Systems  (DIS-160  Tape  Systems) 
Cisco  Systems  (LS-1010  ATM  Switches) 

FORE  Systems  (ASX-1000  ATM  Switches) 
Sprint  (Laboratory  space,  terrestrial  network) 


1 1 8x  Experiment  Participants 

Computer  Industry 


Sun  Microsystems  (Solaris  2.7,  Ultra  workstations) 
Microsoft  (NT  4.0,  NT  5.0) 

Digital  Equipment  (DEC  Unix  4.3,  DEC  Alphas) 
Pittsburgh  Supercomputing  Center  (Integration) 
Intel  (Pentium  II  Development  Systems) 
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Satellite  Industry 


Hughes  Space  & Communications 
Lockheed  Martin  Corporation 
Space  Systems  / LORAL 
Spectrum  Astro 


Introducing  NASA’s  Advanced 
Communications  Technology 
Satellite 


simulator! 
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Ka-Band 


Remote 


Satellite 
Return  Link 
1 to  622  Mbps 


/ 

Terrestrial 
Forward  Links 
1 to  20  Mbps 
Using  NREN 


1 1 8x  Participating  Sites 


NASA  Lewis  Research  Center  (LeRC)  - 
Cleveland,  OH 

Lawrence  Livermore  National  Laboratory 
(LLNL)  - Livermore,  CA 

Sprint  Advanced  Technology  Laboratory 
(ATL)  - Burlingame,  CA 


1 1 8x  End-to-end  Network  Layout 


Sprint  Advanced 
Technology  Laboratory 


NASA 

Lewis  Research  Center 
Cleveland,  Ohio 


High-Speed  Magnetic  Tape  Test 


NASA 

Advanced  Communications 
^ Technology  Satellite 


622  Mbps 
Link 


Sprint 

Advanced  Technology  Lab 
Burlingame,  CA 


NASA 

Lewis  Research  Center 
Cleveland,  Ohio 
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1 1 8x  Double-Hop  End-to-end  Network  Layout 


NASA 

Advanced  Communications 
2*  Technology  Satellite 


Sprint  Advanced 
T echnoloav  Laborator 


536  ms 


LawrenceUvermor^ 

"T^atlonaTIIIaEorator^ 


Two  devices  at  NASA  LeRC 
communicate  with  each  other  through 
the  physical  loopback  at  Sprint.  This 
has  the  effect  of  doubling  the  roundtrip 
delay  between  them 


NASA 

Lewis  Research  Center 
Cleveland,  Ohio 


1 1 8x  Double-Hop  End-to-end  Network  Layout 


NASA 

Advanced  Communications 
^ Technology  Satellite 


/ 622  Mbps  \ 
E Lil*  V 


Sprint  Advanced 
T echnoloav  Laborator 


Lawrence  Livermore 


Two  devices  at  NASA  LeRC 
communicate  with  each  other  through 
the  physical  loopback  at  Sprint.  This 
has  the  effect  of  doubling  the  roundtrip 
delay  between  them 


NASA 

Lewis  Research  Center 
Cleveland,  Ohio 
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Complete  first  phase  workplan  by  end  of 
September,  1998 

Demonstrate  - demonstrate  - demonstrate 

Leverage  relationships  and  technology  base 
to  further  the  state-of-the-art  in  high-speed 
satellite  applications  using  standard  protocols 

Apply  the  technology  to  NASA’s  unique  data 
handling  problems  using  TDRSS 

Leverage  the  architecture  for  space 
commercialization 


Industry  Challenges 


Incorporate  error-recovery  techniques  (like 
those  found  in  SCPS)  into  TCP/IP 

Demonstrate  these  capabilities  to  broader 
audiences 

Implement  the  technology  to  lower  the  cost  of 
building  and  delivering  advanced  applications 
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Internet  over  a Bi-Directional  Satellite  Link 


Jim  Griner 
Mark  Allman 
Paul  Mallasch 
David  Stewart 


Satellite  Networks:  Architectures,  Applications, 
and  Technologies  Workshop 
June  2-4, 1998 


Internet  over  a Bi-Directional  Satellite  Link 

• Comparison  of  HTTP  over  several  network  channels 

- 33.6k  modem  connection 

- Satellite  connection,  standard  TCP  stack  and  typical  application 
settings 

- Satellite  connection,  optimized  for  satellite  networks 

• larger  window  sizes 

• larger  initial  congestion  window 

• TCP  bug  fixes 

• new  versions  of  the  HTTP  protocol 

• By  using  appropriately  tuned  applications  and  TCP  settings,  we 
demonstrate  improved  performance  of  HTTP  when  compared  to 
today's  off-the-shelf  software 

Optimizations  are  based  upon  findings  from  experiments  conducted 
between  satellite  research  networks  at  NASA  Lewis  Research  Center 
and  Ohio  University. 
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Internet  over  a Bi-Directional  Satellite  Link 

Demonstration  Setup 


T1  Wireless  Link 


1 33.6K  Baud 
Modem  Link 


Pathl:  Modem 


Path2:  Satellite,  typical  settings 


Path3:  Satellite,  optimized 


T1GEO 

Satellite 

Link 


Sheraton  Airport  Hotel 


NASA  LeRC 


Internet  over  a Bi-Directional  Satellite  Link 

• HTTP  Comparison  Pages 

- 20  pages  gathered  from  several  Ohio  related  sites 

- Pages  with  varying  attributes 

• Number  of  images  from  1 to  27 

• Image  sizes  from  177  bytes  to  360  kilobytes 

• Demonstration  setup  in  Dulles 

- Three  computers,  one  for  each  of  the  network  channels 

- Pages  are  synchronized  to  start  at  the  same  time 

- The  computers  will  pause  for  one  minute,  before  moving  on  to 
the  next  page 

- The  20  pages  will  repeat  continuously,  for  the  duration  of  the 
workshop 
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Plenary  Session 

TCP  over  Satellite:  Issues, 
Relevance,  and  Experience 


Page  intentionally  left  blank 


Does  TCP  Work  over 
Links  or  Not? 


Dr.  Craig  Partridge 
BBN  Technologies 


ThePuzzle 


TCP  was  designed  to  work  ove^s^tellites 

- the  goal  of  the  research  project  that  created 
TCP  was  to  link  SATNET  and  ARPANET^ 

TCP’s  theoretical  maximum  data  rate  lk  15 
Gb/s  \ 

- faster  than  any  satellite  link  \ 

So  why  do  people  feel  TCP  doesn’t  work 
over  satellites? 


sons 


Bad  reasons 

- out  of  date  implementations 

- misconfigured  TCPs 

- poor  testing  technique 

Good  reasons 

- high  bandwidth 

- TCP  startup  delays 


Out  of  Date  Iftrplementations 

> TCP,  as  specified  in  1981,  hacTJ^siitations 

- max  data  rate  of  1 Mb/s  over  GEO 

- 286  Mb/s  overall  max 

i Limitations  repaired  in  early  1990s 

- PAWS  and  big  windows 

- max  data  rate  now  15  Gb/s  over  GEO 

- 8 Tb/s  overall  max 

- make  sure  you’re  up  to  date! 
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An  up-to-date  implementation^sfoe§n’t  help 
if  you  don’t  configure  it 

Many  TCPs  shipped  with  64KB  maximum'1 
window  size  \ 

64KB/250ms  is  2 Mb/s  \ 

Must  turn  on  PAWS  and  large  windows  anc 
set  default  window  to  be  large!  ' 


Lots  of  people  test  performance&yTaking 
TCP,  out  of  the  box,  and  FTPing^N. 
megabyte  of  data  \ ^ 

That’s  stupid  \ 

- TCP  may  be  misconfigured  \ 

- 1 MB  is  far  too  small  for  anything  but  a LAN> 
Configure  the  TCP,  then  transfer  a gigabyt 


High 


Iwidth 


Moving  from  56  Kb/s  links  tom^gabit  links 
has  implications 

- more  data  in  flight  (more  sender  effort  \o  filf 
the  pipe) 

- error  rates  must  go  down  proportionately 

- big  transfers  get  most  of  the  benefit 


Big  T ransfers^Get  Most  of  the 

Ben^fH 

l Faster  isn’t  really  faster 

- speed  of  light  says  a 1 bit  pulse  takeS 
time  it  always  did 

- faster  really  means  bits  are  thinner  on  the\yire 

l Big  transfers  win;  small  transfers  don’t 

- big  transfers  get  all  their  bits  on  the  line  soonS 

» Web  transfers  are  small... 

- transfer  time  dominated  by  transmission  delay 
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TCP  Startup  Delays 

On  startup,  TCP  probes  a linkl^kam  how 
much  capacity  is  available 

- goal  is  to  avoid  overloading  network; 

- fairly  sharing  with  existing  connections 
Startup  time  depends  on  delay  and 
bandwidth 

- on  a GEO  at  155  Mb/s,  it  takes  11+  seconds 

- first  20  GB  are  sent  during  this  probe  stage 


Forward? 


Recognize  that  terrestrial 
same  problem  with  startup 

So  look  for  general  solutions 

- Hoes’  algorithm 

- pacing 

Avoid  link-specific  algorithms 

- spoofing 
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TCP  OVER  SATELLITES 
ISSUES,  RELEVANCE,  & EXPERIENCE 


Norm  Butts 

Manager,  ITC  Systems  Engineering 
Lockheed  Martin  Telecommunications 


Interactive  Technology  Center 
Norm  Butts  (408)  543-3021 


06/02/98 
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loekhMd  Martin  Talacommunleatlona 


TCP  over  Satellite  Applications: 

• GEO  Fixed  Satellite  Services 

- Internet  Service  Providers  (wholesale) 

- Satellite  Internet  (retail) 

- Private  Networks  (VS AT) 

• GEO  Mobile  Telecom  Satellites 

- email/internet  add-on  services 

• GEO  Direct  Broadcast  Satellites 

-DVB  based  Internet  add-on  Services 

• GEO  Broadband  Satellites 


TCP  Relevance 

(Why  is  Lockheed  Martin  Interested  in 
TCP  over  Satellite) 


- Astrolink 

- Other  Ka  Band  Systems 

Many  customers  are  looking  for  pre-integrated  applications 
Bottom  line:  applications  drive  satellite  sales 


Interactive  Technology  Center 
Norm  Bum  (408)  543-3021 


06/02/93 
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Astrolink  Environment 


f* 


Lockheed  Martin  Telecommunications 


Characteristics: 

- Nine  GEO  satellite  constellation  at  five  locations 

- Frequency : Ka  Band,  20GHz  (downlink)  30Ghz  (uplink) 


- Terminal  Bandwidth:  SOHO  - 384  Kb/S,  Med.  Enterprise  -2.3  Mb/S,  Large 

Enterprise  - 9.2  Mb/S 

- Format:  ATM,  Multi-Frequency  TDMA,  DAMA 

- Latency  (Round  Trip)  & 500 ms  (one  hop)  to  «1.6s  (worst  case  three  hop) 


Performance  of  Today’s  TCP  implementations 

- Win  95  40  Kb/S  (3  hop)  to  128  Kb/S  (1  hop) 

- UNIX  - Many  are  "tunable  "for  better  satellite  performance  but  default  to  similar 

performance  levels 


Conclusion:  Today ’s  TCP  implementations  fall  short  of  needed 
performance 

Interactive  Technology  Center 
Norm  Butts  (408)  543-3021 


06/02/98 


Lockheed  Martin  Telecommunications  | TCP  Satellite  PerfOlTllBnCe 

1 Improvement  Issues 

Improved  End  to  End  TCP  Implementations 

- Many  improved  alogrithms  are  available  or  on  the  way 

- Implementation  by  major  O/S  suppliers  is  the  big  question 

- Fairness  issue  cannot  be  resolved  without  major  changes 

Transparent  Gateways/Proxies  (AKA  Spoofing) 

- Works  with  existing  TCP  implementations 

- Can  overcome  fairness  problem 

- Has  been  used  with  success  in  unidirectional  satellite  w/ dial-up  return  channel 

- Implementation  is  difficult  and  risks  possible  side-effects 

- Lockheed  Martin  is  working  on  a proof-of-concept  bi-directional  gateway 

ATM  Issues 

- Further  research  on  TCP/ATM  interaction  is  required 


Interactive  Technology  Center 
Norm  Butts  (408)  543-3021 


06/02/98 
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Spice  Mission  Operations  Standardization  Program 

National  Aeronautics  and  Space  Administration 


Mixing  TCP  And  Satellites:  A View  From  Above 

( Irreverent  Confessions  From  The  Standards  Trenches ) 


NASA  LeRC  Workshop  on  Satellite  Networks 
Cleveland,  Ohio 
June  2, 1998 

Eric  Travis /NASA  Jet  Propulsion  Labs  (e.j.travis@ieee.org) 


SCPS 


Space  Mission  Operations  Standardization  Program 

National  Aeronautics  and  Space  Administration 


Why  Are  Open  Protocol  Standards  Important? 


• The  Vision: 

- Cheaper,  better,  faster 

- Risk  reduction  & stability 

- Interoperability 

- Efficiency 

• Potential  Problems  In  Realizing  The  Vision: 

- Broad  applicability  not  recognized 

- Flexibility  contends  with  simplicity 

- Deployment  into  an  installed  base 

• Do  You  Get  A “Big  Tent”  Solution  Or  Just  A “Big  Top”  Oddity? 

- Candor,  industry  participation  and  feedback  will  make  the  difference 

• A Parable  For  Our  Times:  Should  The  Tail  Be  Wagging  The  Dog? 
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Space  Mission  Operations  Standardization  Program 

National  Aeronautics  and  Space  Administration 


Protocols  Are  Like  Galoshes:  One  Size  Does  Not  Fit  All 


• The  Dynamic  Range  Of  Network  Environments  Is  Larger  Than  Ever 

- Satellite  networks  mirror  the  full  spectrum:  wireless  to  fiber,  mobile  to  static 

- Environments  are  Opaque:  “On  the  Internet,  nobody  knows  you’re  In  orbit” 

• You  Probably  Own  Only  Part  Of  The  Railroad 

- Actions  at  a distance  can  affect  your  bottom  line  performance 

• TCP  Loss  recovery  is  expensive  and  retransmissions  are  not  always  free 

• Loss  recovery  is  inherently  unfair  to  long(er)  paths 

- Localized  performance  tuning  keeps  the  trains  running  on-time 

• Spoofing  and  proxies:  The  benefits  of  impedance  matching 

• Balancing  security,  transparency  and  the  end-to-end  argument 

• Seamless  Integration  Is  A Matter  Of  Perspective  (Theory  and  Practice) 

• Bottom  line  For  Performance  And  Efficiency  In  The  Near  Term: 

Tailor  Your  Solutions,  Do  So  With  Standardized  Mechanisms  Appropriate  To  The  Environment 

SCPS 
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Performance  Analysis  of  the 
HTTP  Protocol  on 
Geostationary  Satellite  Links 

Hans  Kruse 
Ohio  University 
Mark  Allman 

NASA  LeRC/Sterling  Software 
Jim  Griner,  Diepchi  Tran 
NASA  LeRC 


NASA  Workshop  June  2-4,  1998: 

Satellite  Networks:  Architectures,  Applications,  and 

Technology 


Overview 


• Network  Reference  Points 

• The  HTTP  1.0  and  1.1  Mechanisms 

• Experimental  Setup 

• TCP  and  HTTP  Configuration 

• Results  and  Future  Work 


■?’  Hans  Kruse.  J Warren  McChwe  School  of  Communication  Systems  Management.  Ohio  University,  http  6/1  OSwww  csm.ohiou.edu/ 
kruse 
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Why  HTTP 


• The  Obvious  Answer: 

“Millions  of  Web  Browsers...” 

• The  not-so-obvious  Answer: 

- HTTP  is  a very  generic  multi-file  transfer  protocol 
with  content/encoding  awareness 

- Very  well  optimized  HTTP  servers  are  available 

- HTTP  contains  intrinsic  proxy  support 
mechanisms  that  allow  regional  caching  of  data 


^ Hans  Kruse.  J Warren  McClure  School  ol  Communication  Systems  Management.  Ohio  University,  http  6/1 /98www  esm.ohiou  edu/ 
kruse 


Network  Reference  Points 


v Hans  Kruse  J Warren  McClure  School  ol  Communication  Systems  Management.  Ohio  University.  http:6/1/98www  csm.ohiou.edu/ 
kruse 
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Reference  Points  cont... 


• interface  “a” 

- Very  small  number  of  users 

- Traffic  is  bursty,  user  wants  good  response  time, 
protocols  dominate  performance 

• Interfaces  “b”  and  “c” 

- Large  and  varying  number  of  users 

- Traffic  is  more  random,  performance  depends  on 
protocols  and  congestion  control;  fairness  is 
desirable 


Hurts  Kruse.  J Warren  McClure  School  o»  Communteatron  Systems  Management.  Ohio  University;  http  6/1  ASwww.csm. ohiou.edu/ 
kruse 


The  HTTP  1 .0  Mechanism 


<£>  Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  University;  http  6/1  #8www.csm.oWou  edu / 
kruse 
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i$<  Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  University,  http  6/1  «8wwwcsmohiou  edu/ 
kruse 


The  Experimental  Setup 


Client 

Pentium  Pro 
NetBSD  1.2.1 


Packet 
Capture 
Pentium  Pro 
NetBSD  1.2  1 

Magratbea 


Ohio 

University 

lOBaseT 


Tasha 


Server 

486 

letBSD  12.1 


<P>  Hans  Kruse.  J Warren  McClure  School  of  Coromumcaticn  Systems  Management.  Ohio  University,  http.6/1  SBwww  csmohiou. edu/ 
kiuse 
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TCP  Configuration 


• Standard  BSD  “reno”  stack 

• Large  window  support  (RFC  1323) 

- experiment  uses  8, 1 6,  64,  and  96Kbytes 

• Bug  fixes  in  the  NetBSD  stack 

- Initial  window  starts  with  one  segment 

- Acknowledgments  are  generated  according  to  the 
standard 


©Hans  Kruse,  J Warren  McClure  School  of  Communication  Systems  Management,  Ohio  University:  http:6/1«8www.csm  ohiou.eduf 
kruse 


HTTP  Configuration 


• Apache  Server  (HTTP  1 .0  and  1.1) 

- Persistent  connections  in  HTTP  1 .0 

• Netscape  browser 

• Netscape  allows  multiple  connections 

- experiment  uses  1 , 4,  8,  and  1 6 

• Experimental  HTTP  1.1  client 

• Increased  initial  TCP  window  support 


© Hans  Kruse,  j Warren  McClure  School  of  Communication  Systems  Management,  Ohio  University;  http:6/1fl0www.csm  ohfcju  edu/ 
kruse 
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<g>  Harrs  Kruse  J Warren  McClure  School  of  Communed  Ion  Systems  Management.  Ohio  University;  http:  6/1  «8www  esm  otnou  edu/ 
kruse 


Comparing  HTTP  1.0  and  1.1 


HTTP  1.0  and  1.1  Comparison 


Window 

A 


►—HTTP  1.1  16K 
■ — HTTP1.0  1/16 
fc— HTTP1.1  64K 
I— *— HTTP1.04/16 


Window 


Connections 


Web  Page 


-51  Harrs  Kruse.  J Warren  McClure  School  ol  Communication  Systems  Management,  Ohio  University,  fcttp:6/1  ©8www.csm.eNou  edu/ 
kruse 
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HTTP  1.1 


,jX_*  j * 

////^///// 


'P  Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  University;  http  6/1S8www  csm  ohiou.edu/ 
Kruse 


The  Larger  TCP  Initial  Window 


Modifled  Initial  Window 


" X 1 ■ mod  96K 


Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management,  Ohio  University;  http  6/1/9Bwww  csm.oNou  edu/ 


1 


What  settings  are  important? 


<g>  Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  University;  http  6/1^8 www.esm.ohrou.edu/ 
kruse 


Modeling  Slowstart 


• Based  on  Heideman,  et  al.  (IEEE 
Transactions  on  Networking  Vol.  5,  No.  5,  Oct 
1997. 

• Slowstart  creates  an  exponential  increase  in 
the  data  flow,  up  to  the  channel  bandwidth 

• Delayed  acknowledgements  change  the  rate 
of  increase 

• HTTP  1 .0  requires  a little  extra  work,  results 
for  HTTP  1.1  are  shown  here. 


*■  Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  Unrversity.  http  6/1  &6www  csm  ohioti  edu/ 
Inuse 
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Experiment  vs.  Slow  Start  Model 


16  64 

TCP  Window  (KBytes) 


© Hans  Kruse.  J Warren  McClure  School  of  Communication  Systems  Management.  Ohio  University:  htlp:6/1#8www  csm.ohiou.edu/ 
kmse 


Maybe  a few 


Experiment  vs.  Model  - Modified  initial  Window 


acts 

* acts  Exp. 

Test 

■ Test  Exp. 


8 

16  64 

i 

96 

TCP  Window  (KBytes) 

© Hans  Kruse.  J Warren  McClure  School  of  Cemmunieatrcn  Systems  Management,  Ohio  University;  http.6/1»3www  esm  ohiou.edu/ 
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Implication  for  the  Service 
Provider 


Page 

Best  Time 

Size 

Rate 

Utilization 

No.  of 

Based  on  T1 

(sec) 

(Kbytes) 

KB/Sec 

Users 

(1 ,536Mbps) 

/acts 

3.79 

100 

26.41 

14% 

7.1 

Service 

/LeRC 

3.00 

49 

16.36 

9% 

11.5 

/oufr 

6.89 

491 

71.23 

38% 

2.6 

/Test 

2.99 

29 

9.70 

5% 

19.3 

Desirable  Configuration: 


IV 


Conclusions  and  Future  Work 


• HTTP  1.1  pipelining  outperforms  HTTP  1.0. 

• Performance  of  HTTP  1.1  can  be  readily 
modeled. 

• Pipelining  will  create  new  application  level 
problems. 

• Examine  the  reference  points  “b”  and  “c”  by 
introducing  competing  background  traffic  with 
the  TCP  flow  under  study. 


t.  J W men  McCtute  School  of  Communication  Systems  Management.  Ohio  Umvetstty  . hop  6/1  /MmtH  csm  ohiou.edu/ 
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Performance  Enhancement  for  TCP/IP  over  a 
Satellite  Channel 


J.  S.  Stadler,  J.  R.  Gelman,  L.  L.  Jeromin 


MIT  Lincoln  Laboratory 


1 MIT  Lincoln  Laboratory  ■ 


Satellite  Data  Communications 
Architecture 


On-board  Packet  Switch 

Eh 

Packetized  Uplink  Multiple  Access 

Satellite  Protocol  Enhancement  — 

- Standards 

- Link  Layer  racketed  iL 

- Protocol  Conversion  multiple  access 


EHF  SATELLITE 


ONBOARD 
PACKET  SWITCH 


tvnfaaM 


I -U-  '! 
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Outline 


* Background  - TCP  via  Satellite 

* Lincoln  Laboratory  Link  Layer  Protocol 

* Wireless  IP  Suite  Enhancer 

* Performance  Results 

* Summary 


MIT  Lincoln  Laboratory  “ “ 

NASAJ»_UJ-J 


TCP  via  Satellite 


a TCP  operates  over  a large  range  of  environments  - 
sometimes  at  degraded  levels  of  performance 

- Communication  links  may  not  be  used  efficiently 

- Reduced  QoS  as  perceived  by  an  interactive  user 

* In  a satellite  environment  inefficiencies  can  be  attributed  to: 

- Latency 

GEO  satellites  have  a minimum  0.52  second  RTT 

- Bit  Errors 

Satellite  links  can  be  made  "error  free”  but  a data  rate  penalty  is 
incurred 

- Link  Asymmetry 

Mobile/Portable  terminals  can  typically  receive  much  more  data 
than  they  can  transmit 


MIT  Lincoln  Laboratory 

NASA_WJJJ-4 
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Goals 


° Transparency 

- User  should  not  need  to  know  that  a satellite  link  is  used 

- User  should  not  have  to  follow  special  procedures 

- Perceived  QoS  should  be  acceptable 

* Backward  Compatibility 

- Approach  should  work  with  the  existing  network 
infrastructure 

* Efficiency 

- Approach  should  make  efficient  use  of  the  satellite  link 

* Scalability 

- Approach  should  scale  to  large  systems/data  rates 

* Flexibility 

- Approach  should  be  applicable  with  bent-pipe  or  processing 
satellites 

^ ^ MIT  Lincoln  Laboratory 


Existing  Solutions 


* Internet  Engineering  Task  Force  (ETF)  Standards  Track 

- TCP  Extensions  for  High  Performance  (RFC  1323) 

- TCP  Selective  Acknowledgement  Options  (RFC  201 8) 

- TCP  Fast  Retransmit/Fast  Recovery  (RFC  2001) 

* Alternate  T ransport  Protocols  Designed  for  Satellite 
Environments 

- Satellite  Transport  Protocol 

- SCPS 

- XTP 

* Special  Purpose  Link  Layer  Protocols 

- Lincoln  Laboratory  Link  Layer 

- TCP  Aware  Link  Layer 


NAS  A_St_t  J J-A 


MIT  Lincoln  Laboratory 
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• TCP  ‘Spoofing’ 

- TCP  ACKS  are  manipulated  to  reduce  flow  control  effects 

• TCP  Splitting 

- TCP  connection  is  terminated  at  the  periphery  of  the  satellite 
network 

TCP/TCP 

TCP/Other 


* Background  - TCP  via  Satellite 

* Lincoln  Laboratory  Link  Layer  Protocol 

* Wireless  IP  Suite  Enhancer 

* Performance  Results 

* Summary 
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Lincoln  Laboratory  Link  Layer  Protocol 


0 Link  Layer  protocol  transparently  conditions  the  satellite 
channel  according  to  the  TCP  needs 

* Approach 

- Get  data  flowing  as  quickly  as  possible 

Enable  the  TCP  flow  control  algorithm  to  ramp  up  as  quickly  as 
possible 

- Make  sure  data  continues  to  flow 

Prevent  the  TCP  flow  control  algorithm  from  reducing  the 
transmission  rate  due  to  errors  on  the  satellite  link 

Congestion  on  the  terrestrial  portion  of  the  network  will  still  result 
in  a reduction  in  the  transmission  rate 

- Correct  errors  in  as  efficient  a manner  as  possible 

Efficient  retransmission  mechanism 
Forward  Error  Correction 


NASA_M_LU-9 


MiT  Lincoln  Laboratory «— • 


Lincoln  Laboratory  Link  Layer  Protocol: 
Implementation 


* Fragmentation 

- Decouples  link  layer  packet  size  from  the  TCP  segment  size 

- Larger  TCP  segments  allow  data  flow  to  ramp  up  more  quickly 
without  making  the  packets  more  susceptible  to  link  errors 


* Link  Layer  Selective  Repeat  ARQ 

- Hides  link  errors  from  TCP  and  prevents  errors  from  being 
confused  with  congestion 

- Selective  Acknowledgements  are  sent  on  a periodic  basis 

Acknowledgements  convey  the  entire  receive  buffer  state 

- Packets  received  in  error  are  retransmitted  K times 

- Selective  repeat  ARQ  results  in  packets  being  received  out  of 


@23 

order 
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SM 

i£l 

Packet  reordering  is  necessary 
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SATCOM  UNK 

MIT  Lincoln  Laboratory 
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Outline 


* TCP  via  Satellite 

* Lincoln  Laboratory  Link  Layer  Protocol 

* Wireless  IP  Suite  Enhancer 

* Performance  Results 

* Summary 


1 — " '■  MIT  Lincoln  Laboratory  11 

NASAJHJiJ-l  1 


Wireless  IP  Suite  Enhancer 


* Users  connect  through  a TCP  translator  at  the  boundary  of 
the  satellite  portion  of  the  network 

- Operates  with  no  modifications  to  end  user  systems 

- Applications  are  unmodified 

* Translator  converts  incoming  TCP  connections  to  Lincoln 
Laboratory  Link  Layer  protocol 

- Error  correction  is  performed  locally  on  the  satellite  segment 
of  the  link 

- Peer  translator  will  convert  satellite  protocol  back  to  TCP 

* IP  packets  not  containing  TCP  packets  are  encapsulated  in 
a link  layer  protocol  (error  correcting  optional) 


■ MIT  Lincoln  Laboratory 

NA5A_»J-U-I2 
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Wireless  IP  Suite  Enhancer 

(WISE) 


SATELLITE 


NASAJBJJJ-1J 


MIT  Lincoln  Laboratory 


Outline 


* Background  - TCP  via  Satellite 

* Lincoln  Laboratory  Link  Layer  Protocol 

* Wireless  IP  Suite  Enhancer 
— ► • Performance  Results 

* Summary 


NA5A_9B_IJ  J-M 
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PC  2 


PC  4 


Uwr 

Equipment 


NASA_«_tAM5 


StttfHaHarmt 


User 

Equipment 
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Test  Results 


* Test  scenario 

- 100  Kbps  link 

- 10-*  error  rate 

- -2048  bit  packets  (nominal)  over  satellite  link 

- 1 Sec  RTT  delay 

- WWW  applications 

- Configurations 

TCP  - optimized  TCP  parameters 
TCP/LLLL  - default  TCP  parameters 
TCP/WISE  - default  TCP  parameters 


1 1 111  111  MIT  Lincoln  Laboratory 

NASA_9*_LLJ-lft 
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0 10  20  30  40  50  60  70  80  90  100 

File  Size  (Kbytes) 

ii  ii  i 1 MIT  Lincoln  Laboratory 

NASA_«U.U-J7 


Instantaneous  Utilization 

(1  Session) 
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Instantaneous  Utilization 

(5  Session) 


HTTP  Link  Utilization  vs.  Time 


“ 1 i— — MIT  Lincoln  Laboratory 

NASA.9IJLIJ-I9 


Summary 


* TCP/IP  often  operates  at  reduced  levels  of  performance  in  a 
satellite  environment 

* The  Wireless  IP  Suite  Enhancer  was  designed  to  substantially 
reduce  the  impact  of  wireless  links  on  the  Internet  protocol  suite 

- TCP  connections  are  converted  to  LLLL  for  transmission  over  the 
satellite  segment 

- IP  packets  not  containing  TCP  packets  are  encapsulated  in  the  LLLL 

* Performance 

- Test  results  show  nearly  optimal  link  utilization  and  significant 
reductions  in  transfer  times  using  commercial  applications 

* Planned  / Ongoing  enhancements 

- Compression 

- IPSEC 

— MIT  Lincoln  Laboratory  “ ““ 

NASA_9*_UJ-2n 
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Estimating  Bottleneck  Bandwidth 
using  TCP 


June,  1998 


Mark  Allman 

NASA  Lewis  Research  Center 

mallmanQlerc . nasa . gov 

http:  //gigahertz,  lerc.  nasa.gov/~mallman 

Hit  our  satellite  with  feeling 
Give  the  people  what  they  paid  for 
-The  Flaming  Lips 


• Why  do  we  want  TCP  to  estimate  the 
bottleneck  bandwidth? 

- Startup  more  rapidly 

- Avoid  loss 

• We  will  concentrate  on  estimating  the 
bottleneck  bandwidth  in  order  to  set 
ssthresh  to  an  appropriate  value  and  thus 
avoid  loss. 

- "Satellite  friendly"  TCP  often  includes 
large  windows 

- Large  windows  can  allow  a TCP  to 
overwhelm  a gateway  with  a larger 
number  of  segments  than  a small 
window  connection 

- Therefore,  estimating  the  bottleneck 
bandwidth  can  help  TCP  limit  loss  by 
slowing  down  before  overwhelming  the 
gateway 
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• Making  an  estimate  of  the  bottleneck 
bandwidth  has  been  proposed  and  tested 
via  simulation  (Janey  Hoe  at  MIT) 

- used  packet-pair  algorithm  on  the  first 
few  returning  ACKs 

- the  time  between  successive  ACKs  is 
caused  by  the  data  segments 
"spreading  out"  based  on  the 
bandwidth 

- the  bandwidth  estimate  combined  with 
the  measured  RTT  can  be  combined 
to  give  the  appropriate 
delay-bandwidth  product  of  the  link 
and  therefore,  the  correct  window  size 


• However,  real  networks  make  predicting 
the  bottleneck  bandwidth  more  difficult 

- delayed  ACKs 

• getting  successive  ACKs  requires 
more  segments 

- network  jitter 

* traffic  from  other  connections 
getting  between  two  successive 
packets 


- asymmetric  networks 


« So,  how  do  we  get  around  these  problems 
caused  by  real  networks? 

- watch  the  incoming  ACKs  for  a longer 
period  of  time 

• The  larger  the  window  grows,  the  more 
important  it  is  to  avoid  loss  (due  to  the 
possible  magnitude  of  the  loss  event) 

- As  the  window  increases  and  we  get 
more  segments  into  the  network  the 
problem  of  delayed  ACKs  naturally 
fades 

- Network  jitter  can  be  averaged  out  if 
we  are  able  to  watch  the  ACKs  for  “a 
while" 

- Asymmetric  networks? 

• Hmmm... 


liEMiinany^R^^ 


• We  collected  packet-level  traces  from 
various  networks  and  analyzed  attempted 
to  determine  the  bandwidth  of  the 
bottleneck  link  based  on  the  ACK  stream 

• ACKS  were  observed  in  the  order  in  which 
they  arrived  only,  as  to  attempt  to 
simulate  a TCP  stack 
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• We  ran  several  FTPS  over  the  ACTS 
satellite  and  were  able  to  successfully 
estimate  the  bottleneck  bandwidth  (and 
therefore,  the  appropriate  window  size) 
within  the  first  40  segments  (data  and 
ACK)  observed. 

• This  environment  was  free  from 
competing  traffic  so  it  is  mostly 
uninteresting 

- But,  it  shows  that  delayed  ACKs  do 
not  make  the  task  impossible 


• We  ran  several  FTPs  between  LeRC  and 
OU  to  obtain  traces  from  a dynamic 
environment  with  competing  traffic 


• We  were  able  to  determine  a “good” 
window  size  within  the  first  50  segments 
observed 

— Our  estimate  is  60%  higher  than  the 
window  size  needed  to  obtain  the 
throughput  we  observed,  on  average 

• window  / RTT  = bandwidth 

— Our  estimate  is  66%  lower  than  the 
window  size  at  which  loss  occurred,  on 
average 


• Therefore,  we  hypothesize  that  a TCP 
using  this  algorithm  would  perform  just  as 
well,  if  not  better  than  a TCP  without 
bandwidth  estimation  (on  average) 
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• But,  sometimes  the  estimate  is  not  all 
that  "good" 

- If  the  estimate  is  too  low,  we 
terminate  slow  start  too  soon  and  then 
depend  on  congestion  avoidance  to 
provide  window  growth 

• Slow! 

- Estimating  too  high  is  not  as  big  a deal 
as  we  can  do  no  worse  than  current 
implementations  and  possibly  avoid 
some  loss,  even  when  we  overestimate 


- Refine  algorithms  used  to  average  the 
inter-ACK  space 

- Test  in  a hybrid  terrestrial/satellite 
network 

- Other  mechanisms  can  be  investigated 
once  we  have  a good  estimate  of  the 
bandwidth 
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LFN  and  SACK  over  DVB  Satellite  links 


Nihal  Samaraweera  and  Gorry  Fairhurst 
Department  of  Engineering 
University  of  Aberdeen 
Aberdeen 
UK 

email:  {nihal, gorry}@erg.abdn.ac.uk 
http:  //www.erg.abdn.ac.uk/ 


DVB  Networking 

N Samaraweera  and  G Fairhurst,  Univers-ty  of  Aberdeen 


Same  satellite  dish  receives  TV  and  Internet  traffic 
High  speed  Internet  access  to  home  and  office 
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What  is  a Long  Fat  Network? 

N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 


High  bandwidth  delay  product  (e.g.,  Satellite  link) 
Many  terrestrial  networks  are  more  “fat”  than  “long” 


TCP  Window  Limitation 

N Samaraweera  and  6 Fairhurst.  University  of  Aberdeen 


TCP  unable  to  keep  the  fat  pipe  full 

Throughput  limited  by  maximum  window  size 

(e.g.  performance  over  a satellite  link  limited  to  < 1 Mbps) 

Window  scale  option 

(RFC  1072,  RFC  1185,  RFC  1323,  IETF  draft-tcp-lw) 

Expands  the  16  bit  TCP  window  to  32  bits  (i.e.  < 1 Gbps) 
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Congestion  window,  etc  [Kbytes]  ^ TCP  Throughput  [Kbps] 


10000 


I I 100ms  return  delay 


N Samaraweera  and  G Fairtuirst,  University  of  Aberdeen 


200ms  return  delay 


300ms  return  delay 


JflfH  Configuration: 

I I'j  JBB  I - ijl  — SfoBJ — Wf  WpBU  TCP  MSS:  1024 

64  128  256  512  720  Satellite  delay:  280ms 

C!-.«  rirm  Link  bandwidth:  34Mbps 

Window  Size  [KB]  3 sessions  sharing  the  link 

Simulation  time:  60  seconds 

indow  scaling  is  useful  for  > 1Mbps  over  a satellite  link 


Standard  TCP,  Window 

N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 


Congestion  window 
Threshold  window 
TCP  window 
Bytes  in  transit 


Configuration: 

TCP  MSS:  1024 
TCP  window  size:  64KB 
Satellite  delay:  280ms 
session  bandwidth:  10Mbps 
Simulation  time:  50  seconds 


Transmission  rate  is  restricted  by: 

The  TCP  window  size  (for  small  windows) 

The  congestion  window  (for  small  file  and  large  window) 
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Window  Scaling 

N Samaraweera  and  G Fauhurst.  University  of  Aberdeen 

— Congestion  window  (64KB  window) 

— Threshold  window  (64KB  window) 

- TCP  window  (64KB) 

— ~ Bytes  in  transit  (64KB  window) 

Congestion  window  (700KB  window) 

Threshold  window  (700KB  window) 

TCP  window  (700KB) 

bytes  in  transit  (700KB  window) 


Configuration: 

TCP  MSS:  1024 
TCP  window  size:  700KB 
Satellite  delay:  280ms 
session  bandwidth  10Mbps 
Simulation  time:  50  seconds 

0 10  20  30  Time  [sec]  50 

Only  useful  when  file  size  > 126KB  (over  a satellite  link) 
Example  Applications: 

WWW  based  distance  learning  (CAL),  News  distribution 


TCP  Packet  Loss  Recovery 


Mil 


Standard  TCP  ACKs 
carry  cumulative  ACKs 


Additional  information 
carried  by  SACK  option 


TCP  may  only  efficiently  recover  one  packet  per  window 

A long  fat  network  may  loose  more  packets 
Selective  ACK  Option  (SACK) 

Efficiently  handles  multiple  packet  loss 
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(A)  SACK  resumes  the  transmission  after  retransmission 

(B)  SACK  selectively  retransmits  only  packets  lost 


Retransmission  Packet  Loss  Detection 


it  N Samaravveera  and  G Fairhurst,  University  of  Aberdeen 

— Loss  of  retransmitted  packet 
- — Loss  of  new  packet 


. Additional  information 
1 * 1 “ * 1 * * ' ‘ carried  by  SACK  option 

Packet  5 has  been  SACKed,  but 
packet  2 has  not  been  ACKed 

Indication  of  loss  of  retransmitted  packet  2 

m 

^^Sending  Order  during  the 
Fast  Retransmission  phase 

Uses  transmission  order  and  additional  SACK  information 
Uses  3 SACKs  to  avoid  confusion  due  to  mis-ordering 
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Performance  of  RPLD 


(A)  Avoids  Slow  Start  (does  not  wait  to  drain  the  pipe) 

(B)  Recovery  delay  is  low  (indicated  by  SACKs) 


Asymmetric  links 

N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 


Inexpensive  low  speed  return  links  are  often  used 
Most  TCP/IP  connections  receive  much  more  than  send 
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ACK  Congestion 


Return  “pipe”  fills  with  ACKs 

Transmission  rate  controlled  by  received  ACK  rate 

Therefore  need  to  reduce  volume  of  ACK  data  !!! 


Configuration 


Bandwidth  Asymmetry  1:  1041  (9.6kbps/10Mbps) 

1:347  (28.8kbps/1  OMbps) 


N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 


Data  asymmetry  1: 22  (ACK/MSS) 

Causes  ACK  congestion 

when  bandwidth  asymmetry  > data  asymmetry 

with  ACK  delay,  bandwidth  asymmetry  > N * data  asymmetry 

avoids  congestion  over  9.6  kbps  link  when  N > 47 

over  28.8  kbps  link  when  N > 16 

Note  : TCP  MSS  = 1024B,  TCP  ACK  = 40B,  and  Link  overhead  = 6B 
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N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 

Old  ACKs  may  be  deleted  from  the  return  interface  queue 

TCP  ACKs  are  cumulative  a„„r  7.  "TT7T 


Suppression  ratio  adapts 

Avoids  congestion 


— Unmodified  - (A) 

Using  Compression  - (B) 

• - Using  Suppression  - (C) 


Z fit v.. ' V, 7ZZ: ,1 

^ 0 5^f  10  15 Time  [sec] 25  30 


Low  performance  for  small  files 

Transfer  <1.2  MB  (with  9.6  kbps  return  link) 


Low  Throughput  with  Suppression 

N Samaraweera  and  G Fairhurst,  University  of  Aberdeen 

Suppression  looses  important  information 

An  ACK  indicates: 

(a)  A packet  has  left  the  network  (to  increase  cwnd) 

(b)  Receiver  may  accept  more  data  (to  slide  the  window) 

800, , , , 

. - — — Unmodified  - (A) 

Using  Suppression  - (B) 

J>600. 

^ Slope  determined  by  ACK  / 

^ size  and  link  speed  /' 

1 400  \ ’ t 


IS  200 

no 

a 

o 

U 


A feed  to  increase  A CK  rate  0 L 

without  increasing  the  bandwidth  0 


10  15  Time  [sec]  25  30 
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ACK  Compaction 

N Samaraweera  and  6 Fairhurst.  Universdy  of  Aberdeen 

Reduces  ACK  size  but  not  rate 
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Issues  to  be  resolved: 

ACKs  may  need  be  spaced 
Interaction  with  SACK  option  £ o 
Interaction  with  timestamps  option 
Interaction  with  security 


o 


~ Unmodified  - (A) 

- Using  Compression  - (B)  ^ 
• Using  Suppression  - (C)/ 

--  Using  Compaction  - (D) 
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(A) 


10  15  Time  [sec]  25  30 


Conclusions 

N Samaraweeia  and  G Fairiiuist.  Univeiady  of  Abordeon 

Issues  Discussed 

Window  scaling  important  for  > 1Mbps  and  transfer  >126  KB 
SACK  is  important  (very  difficult  to  eliminate  congestion) 
RPLD  useful  over  long  delay  networks 
Volume  of  ACK  data  should  be  reduced 
Some  hard  questions  still  need  to  be  answered!! 

Impact  of  SACK  on  the  asymmetric  modifications 
Pacing  of  transmission  is  important 
Impact  of  satellite  delay  on  short  transfers 
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Abstract 


Lewis  Research  Center's  Space  Communications  Program  has  a 
responsibility  to  investigate,  plan  for,  and  demonstrate  how  NASA 
Enterprises  can  use  advanced  commercial  communications  services  and 
technologies  to  satisfy  their  missions’  space  communications  needs. 

This  presentation  looks  at  the  features  and  challenges  of  alternative 
hardware  system  architecture  concepts  for  providing  specific  categories 
of  communications  services. 
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Background  Regarding  “Commercial  Utilization” 

Potential  Service  Categories 

System  Architecture  Concepts 

Features  and  Challenges 

Conclusions 
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Lewis  Research  Center 


Commercial  Utilization 


“In  the  conduct  of  these  research  and  development  programs, 
NASA  will  seek  to  privatize  or  commercialize  its  space 
communications  operations.’ 

‘U.S.  Government  agencies  shall  purchase  commercially 
available  goods  and  services  to  the  fullest  extent  feasible  and 
shall  not  conduct  activities  with  commercial  applications  that 
preclude  or  deter  commercial  space  activities  except  for  reasons  of 
national  security  or  public  safety." 

- White  House  National  Space  Policy 
Civil  Space  Guidelines 
Commercial  Space  Guidelines 
September  19, 1996 
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Lewii  Research  Center 


Commercialization  of  NASA  Technology  & Services 


NASA 


Industry 


NASA  Utilization  of  Commercial  Technology  & Services 
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Lewis  Research  Center 


LeRC  Role 


Lewis  Research  Center’s  Space  Communications  Program  has  a 
responsibility  to  investigate,  plan  for,  and  demonstrate  how  NASA 
Enterprises  can  use  advanced  commercial  communications  services 
and  technologies  to  satisfy  missions’  space  communications  needs. 

Identify  candidate  commercial  SatCom  systems  to  be  leveraged 

- Develop  an  implementation  plan  for  aligning  NASA’s  needs  with 
commercial  capabilities 

- Select,  develop  and  demonstrate  enabling  technologies  and 
services  to  mitigate  risk 

- Enhance  U.S.  industry  capabilities  and  competitiveness 
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Lewis  Research  Center 


NASA’s  use  of  commercial  communications  systems  requires  both: 

- physical  links  and  interfaces  compatible  with  commercial  space  and 
terrestrial  network  infrastructures 

- compatible  data  communication  network  protocols 

This  presentation  focuses  on  alternative  architectures  for  the  physical 
communications  system: 

- to  establish  the  necessary  framework  for  interoperability  with 
commercial  space  and  terrestrial  networks 

- to  effectively  enable  the  suite  of  desired  communications  services 
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Potential  Service  Categories 


ervice  Category 


ppncations 


TlWI  pt  f 


1 ,7-1  £.'7*1  iT-1 1 


* 

communications  for  humans  in  space 

Wideband  tele-science 

Asymetrical,  experiment  configuration, 
command,  and  scientific  data  return 

Broadband  tele-presence 

Nearly  continuous,  real-time  interaction 
with  space  segment 

High-capacity  storage  and 
distribution 

Latency-tolerant,  content-rich  data,  file 
transfers  to  Pi’s  and  archives 

On-demand  integrated  services 

Real-time  video,  data,  and  voice, 
“Spacecraft  on  the  Internet" 
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Features 


Challenaes 


• Onboard  data  storage  and  burst 
data  delivery 

• 1 .2  Gbps  downlink  in  commercial 
K-band 

• ~10  Mbps  uplink  if  needed 

• Multi-beam  phased  array 

• Efficient  digital  modem  / codec 

• 1 .8-m  tracking  terminals 

• Located  to  maximize  contact 

• Terrestrial  interoperability  for 
wide  area  distribution 

• - 72  Gigabits  / 1 minute  contact 

• No  reliance  on  relay  satellites 

• Experimental  capability  in  2002 


Latency  tolerant  applications 
only 

Onboard  storage  sufficient  for 
multiple  orbits 

Fast  acquisition  and  tracking 
Limited  contact: 

- once  per  orbit  at  poles 

- 1 or  2 per  day  elsewhere 
Commercially  owned,  licensed, 
& operated  on  NASA 
spacecraft  & ground  segment 
Close  coordination  with 
commercial  gateways 
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Available  Standard  Services 


Architectural  Concept  2 


L-,  Ku-,  Ka-band 
GEO  / non-GEO 
ComSats 


IJnder-subscribed 

Areas 


Terrestrial 

/Networks 


Fixed  & Mobile  Satellite  Services 


NASA  Pi’s 
and  Archives 
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I N ASA 


Features 


Challenaes 


• Capture  available  or  unused, 
unmodified  commercial 

L-,  Ku-,  and  Ka-band  capacity 

• Global  narrowband  coverage 

- Multiple  64-kbps  circuits 

- TT&C,  Low-rate  data,  voice, 

• Periodic  wideband  coverage 

- 1 to  25  Mbps  Forward  Link 

- 10  to  155  Mbps  Return  Link 

- interactive  telescience,  video 

• 33  to  nearly  100%  Coverage 

• Narrowband  demo  in  1998 
(STS-91  Spacehab  - Inmarsat) 

• Wideband  demos  in  2003 


• Current  global  coverage  limited 
to  voice  rate  applications 

• Wideband  transponders  cover 
populated  areas  only 

• Close  coordination  to  avoid 
wideband  interference 

• Handoffs  for  non-GEO  coverage 

• Sufficient  business  case  to 
provide  capacity  over 
unpopulated  areas 

• Regulatory  issue  regarding  S-S 
use  of  S-E  and  E-S  allocations 
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Commercial  Tracking  Relay 

Le»i»  Reievdt  center  Architectural  Concept  3 


Ka-  & Q/V-band 
GEO  / non-GEO 
ComSats 


Emerging  Commercial 
Broadband  Services 


Challenges 


Features 


• Semi-custom  rf  or  optical  inter- 
orbital tracking  links 

• Periodic  to  continuous 
broadband  coverage 

- 10  to  55  Mbps  forward  link 
- 155  to  622  Mbps  return  link 

- Interactive  telepresence 

• Video,  Data,  Voice,  Multicast 

• 33  to  100%  Coverage 

• Commercial  Ka-  and  V-band 

• “First  generation  commercial 
transceiver”  for  NASA 

• Service  demos  in  2004 

• Available  commercially  in  2005 
to  2010 


Semi-custom  modification  to 
planned  systems 
Handoffs  for  non-GEO  system 
coverage 

Sufficient  business  case  to 
provide  global  coverage 
NASA  / Industry  development 
of  a common  space  interface 
Commercially  owned, 
licensed,  & operated  on  NASA 
spacecraft 
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Conclusions 


Opportunities  are  present  and  increasing  for  NASA  missions  in  near-Earth 
orbit  to  use  commercial  satellite  services  in  the  future. 

No  single  commercial  system  is  likely  to  provide  the  entire  range  of 
services  desired  by  NASA  missions. 

Proposed  concepts  present  technical,  regulatory  and  economic  challenges, 
but  none  appear  to  be  insurmountable. 

Commercial  systems  have  limited  windows  of  opportunity  for  modification. 

Govemment/lndustry  collaboration  is  required  on  interoperability  standards 
for  a common  space  interface  to  commercial  satellite  networks. 

Communications  services  first  provided  for  NASA  may  have  potential  to  open 
new  markets  for  the  U.S.  satellite  industry. 
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Examines  technical  and  operational  issues  related 
to  supporting  a NASA  LEO  satellite  with 
commercial  satellite  systems 

Four  commercial  satellite  systems  are  addressed 
in  this  presentation 

- Mobile  Satellite  Service  (MSS):  IRIDIUM,  ICO  (1st  gen) 

- Fixed  Satellite  Service  (FSS):  Spaceway,  Teledesic 


Evaluation  Approach 


Communications  Coverage:  Geometric  coverage 
time  minus  system  acquisition  and  service 
acquisition  time. 

- Accounts  for  time  required  for  handoff 

- Accounts  for  dropped  calls  due  to  handoff  failure 

NASA  user  terminal  assessment  including 
spacecraft  G/T,  EIRP  and  operational  constraints 
relating  to  system  acquisition,  service  acquisition 
and  handoff 


Regulatory  assessment 


mpfion 


• No  modifications  will  be  made  to  commercial 
satellite  systems  to  support  NASA  missions. 

- NASA  LEO  satellite  will  emulate  a ground-based  user 

• User  spacecraft  tracking  will  not  be  performed  by 
the  commercial  satellite  systems. 

- Future  NASA  missions  will  incorporate  on-board  GPS 
equipment 

• All  evaluations  of  the  commercial  satellite 
systems  are  based  on  public  information  obtained 
from  FCC  filings 


NASA  LEO 
Missions  Overview 


• NASA  missions  operate  in  a number  of  different 
orbits  that  depend  on  the  mission  type 

- Launch  vehicles  at  approximate  altitudes  of  up  to  350  km 

- Suborbital  missions  at  altitudes  less  than  40  km 

- Manned  space  flight  at  altitudes  of  300  - 600  km  altitude  and 
inclinations  of  28c-  57° 

- Astrophysics  missions  at  altitudes  of  400  - 600  km  altitude  and 
inclinations  of  23°-  35° 

- Earth  science  missions  at  altitudes  of  350  - 1,350  km  and 
inclinations  of  35°-  99° 

• Considered  missions  scheduled  through  2014 

• Data  requirements  range  from  1 kbps  to  600  Mbps 

- Telemetry  and  Command:  1 kbps  to  2 Mbps 

- Payload  data:  1 kbps  to  600  Mbps 
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• Geometrical  coverage  determined  through 
Communications  Analysis  Graphical  Environment 
(CAGE)  simulation 

- Ten  day  orbit  simulation 

- Commercial  satellite  user  antenna  beam  modeled  as  a single 
conic 

• Communications  coverage  determined  through 
CAGE  simulation 

- 30  random  user  satellite  orbit  periods 

- User  satellite  is  positioned  at  a randomly  selected  accession 
angle  prior  to  each  simulation  pass 

- User  antenna  beam  modeled  at  sub-beam  level 

- System  acquisition  time  based  on  IS95  specification  (16.3  sec) 

- Service  acquisition  time  based  on  IS95  specification  (20.0  sec) 

- Handoff  time  based  on  existing  ground  based  cellular  system 
performance  (12  s) 


Simulation  Results 


emerging  commercial  satellite  systems  are  designed  for  users  a 
or  near  ground  level.  Communications  coverage  at  LEO  altitudes 
is  constrained. 

- Reduced  communications  coverage  exist  at  LEO  altitude  due  to  the  conic  shape 
of  the  radiating  antenna 

- Beam-to-beam  handoff  for  a LEO  spacecraft  will  experience  a higher  call  drop 
probability  than  a terrestrial  user  due  to  user  spacecraft  velocity  (12  km/sec) 

None  of  the  evaluated  systems  is  capable  of  supporting  the  real 
time  communications  coverage  requirements  of  manned  space 
flight  missions  and  launch  vehicles 

IRIDIUM  and  Teledesic  provide  the  least  communications  coverage 

- Orbits  similar  to  NASA  LEO  spacecraft 

- Less  than  1%  communications  coverage  for  user  altitudes  > 500  km 

ICO  provides  higher  communications  service  duration  and  data 
throughput 

- Service  availability  20%  • 40%  for  user  altitudes  > 500  km 

Spaceway  (GEO)  provides  highest  communications  service 
duration  and  data  throughput 

- Service  availability  is  greater  then  35%  for  user  altitudes  > 500  km 

- NASA  LEO  satellite  must  support  beam-to-beam  handoff  (not  available  on  FSS) 
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Communications  Coverage 

IRIDIUM 


IRIDIUM  Service  Availability  Analysis  Results  ,J 


399  kn,  598  kn,  798  ka,  599  km,  799  feat, 

2I3<((  ) 21.5  4 (B  I 29.5  deg  ! 57.®  dig  99.2  deg 
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1.  The  « i line  ted  mesa  sab-beam  FOVbnc  (sac)for  Cases  I through  5 a*  foSows:  1)21.9  seconds.  2)  11.4 
seconds,  3)3.0  tecoadi.4)  I M seconds.  3)3.0  seconds. 

2.  The  eitunetad  mean  iub-b«»ji  overlap  tine  (icc)forCaiei  1 fhroegh  5 as  foDowi:  1)5.9  seconds,  2)3.1 
seconds,  3)0.1  seconds,  4)3.1  seconds,  5)0.9  seconds. 

3.  41  spot  beans  per  IRIDIUM  sate  Rite 
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ICO  Service  Availability  Analysis  Results’  * 


300  kn,  500  ka,  700  ka,  500  ka.  700  ka. 

28.5  deg  | 21.5  dec  21.5  deg  57.0  deg  93.2  deg 


sjeaMLZJt 

1.  The  estroa  ted  mean  sub-beam  FOV  time  (sec)  for  Cases  1 through  5 as  fotows:  1)63.7  seconds,  2)57.8 
seconds,  3) 53.0  seconds.  4) 57.8  seconds,  5)53.2  seconds. 

2.  The  estimated  mean  sub-beam  overlap  tine  (sec)  for  Cases  1 through  5 as  fofiows:  1)  17 2 seconds,  2)  15.6 
seconds,  3)  14.4  seconds,  4)  15.6  seconds,  5)  14.4  seconds. 

3.  1 63  spot  beams  per  ICO  s ateBe 
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ICO  FOV  COVERAGE  AT  300  km 
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ICO  FOV  COVERAGE  AT  700  km 
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Communications  Coverage 
Spaceway 


Spaceway  Service  Availability  Analysis  Results’ •’ 


1.  The  estimated  mean  sub-beam  FOV  time  (tec)  far  Cues  1 through  5 ■*  follows:  1)  154.0  second!,  2)  149.0 
seconds,  3)  144.0  seconds,  4)  149.0  seconds,  3)  144.0  seconds. 

2.  The  estimated  mean  sub-beam  overlap  time  (sec)  far  Cases  1 through  S as  falfaws:  1)41.6  seconds.  2)40.1 


3Mksi,  5M  tun,  7W  km,  SM  km.  7Mkn, 

1>J  deg  | 21.5  deg  | 21.5  deg  57  « deg  91.2  deg 
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Spaceway  FOV  Coverage  at  700  km  altitude 


User  Terminal  Assessment 


• NASA  LEO  spacecraft  will  require  a smaller 
terminal  than  TDRSS,  for  MSS,  systems  due  to 
MSS  LEO  and  MEO  constellations 

• FSS  systems  do  not  provide  NASA  LEO 
spacecraft  any  substantial  terminal  size 
advantage  over  TDRSS 

- GEO  systems  are  designed  to  support  ground  users  and 
require  a high  G/T  and  EIRP  to  support  high  burst  rate  TDMA 

• Large  number  of  satellites  in  commercial 
constellations  will  increase  NASA  spacecraft 
memory  and  processing  burden 

- Need  to  determine  when  and  where  data  can  be  transmitted 

• Additional  processing  burden  for  NASA  satellites 

- Doppler  correction,  power  management,  burst  transmission 
management  (TDMA),  and  beam-to-beam  handoff 


Regulatory  Considerations 


Services  provided  by  commercial  satellite 
systems  are  governed  by  International  Radio 
Regulations. and  U.S.  statutes 

Definitions  of  MSS  and  FSS  do  not  provide  for 
space-to-space  links  required  for  NASA  support 

NASA  service  support  scenarios  would  require 
regulatory  amendments 

- Feasibility  studies 

- Marketing  efforts 

- 4 to  14  year  estimated  implementation  time 
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OhioView:  Distribution  of  Remote 
Sensing  Data  Across  Geographically 
Distributed  Environments 


June  2,  1998 
Calvin  T.  Ramos 
LeRC  Project  Lead 
calvin.ramos@Ierc.nasa.gov 


Background 


USGS 

EROS  Data  Center 
Sioux  Falls,  SD 


Drivers 


NASA  Research  and  Education  Network 
(NREN) 


a Access  to  earth  science  products  and 
information 


Bowling  Green 
State  University 


Kent  State 
University 


A Application  of  the  next  generation  of 
satellite  data 

A EOS  Air.-l  and  LandSat  7 


NASA  Lewis 
Research  Center 
Cleveland,  OH  "* 


A Unique  partnership  between  the 
Ohio  state  science  and  library  communities  in 

University  the  State  of  Ohio 


University 
of  Cincinnati 


Ohio 

University 


21 


^ 

W///f/  \v 
■f/llll  . # lltli 
Hr#fiffffi.^»utmp 
Iffffl  lllii.lh  m« w 

i| 

llll  HmilUMH 
liMflVWMml 
!■■  iiirF#Mi|n 
llllVI/i^M|H 

liiiir//j|^B| 


/ 


ft  GIBN  Experiment 
Augmentation 
ft  Processing  of 
ASTER  Data 
ft  Address  hybrid 
interoperability 
issues 


Potential  Areas  of  Network 
Investigation  & Research 


W'A 


/ 


OhioView 

Server 


f Computing 
Communicati 
Facilities, 


l Mass  Storage; 
\NetworttX 


ft  Wide  Area  Multicasting 
ft  Terrestrial 
ft  Satellite 
ft  Security 

ft  Mitigate  LeRC  Risks 
ft  Data  Owner  Protection 
ft  Emerging  Products/Schema 
ft  Security  Policies 
ft  Quality  of  Service 
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OhioView  Public  Network  Model 


NASA 

Visualization 

Server 


1 . Users  initiate  a seacrh  of  the  Miami  Clearinghouse 

2.  Retrieved  metadata  records  point  to  data  location 

3.  User  can  then  choose  to  download  full  dataset  or 
manipulate  the  data  set  with  the  visualization  server. 
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PHASE  II 

Proof  of  Concept 

> 

Develop  and  Implement  Scalable 
OhioView  Pilot 

Implement 
Production  Service 

NREN  Testing 

Network  Perf.  Integ/ Anal. 

LeRC  Role  - TBD 

Storage  Integration 

Storage  Prototype 

Visualization/  Web  Server 

Graphics/Visualization 

Proj  Mgmt/Sys  Integ 

Web  Access/Development 

Phase  lb  prep 

Proj  Mgmt/Sys  Integ 
Prep  for  Phase  n 
Consulting/Outreach 

* LeRC  playing  a key  role 
6 OhioView  - a potential  national  model 
ft  Complex  - both  technically  and  politically 
ft  Great  value  to  broad  community 
ft  Wide  application  of  the  next  generation  of  satellite  data 
ft  Unique  partnership  between  the  science,  library,  and 
state/federal  communities  in  the  State  of  Ohio 
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The  Context  of  the  Project 


Packet  telemetry  is  acceptable  for  spacecraft. 


End  users  rely  heavily  on  Internet  IP  networks  for 
scientific  data  exchange  and  collaborative  research. 

Emphasis  on  cost  reduction  characterizes  all  phases  of 
future  space  missions. 


Distinctive  Features  of  the  Project 


Simple  - SAFE  provides  only  a few  basic  functions. 

• Simple  Automatic  File  Exchange  is  only  that! 
Nevertheless,  it  is  sufficient  for  commands  and  data. 

* Provides  a major  benefit  for  space  scientists  with  only 
a minor  investment  in  development. 

• Aims  to  use  commercial  equipment  and  practices. 

* Solves  well  known  problems  affecting  IP  in  space  by 
avoiding  features  that  expose  the  problem. 

Technical  Features 

* Pulls  data  files  across  the  Internet  with  a read 
operation  (like  file  read  operation  in  NFS). 

■ Prearranged  file  names  - no  file  discovery  mechanism. 

• UDP  packets 

‘ Congestion  control  at  application  level 

■ Simple  solution  to  the  Mobile  IP  problem 
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Final  Goal 


Fleets  of  Small  Satellites  will  report  back  to  data 
centers  operated  directly  by  the  project  by  means  of 
occasional  communication  contact  with  ground 
stations  in  a consortium  of  shared  facilities. 


* 


ared  fi 


* 


^jq 


The  ground  systems  are  shared  by  the  project  data 
centers  and  all  are  connected  via  an  Internet.  There 
are  no  operational  costs  for  routine  command  uploads 
or  instrument  data  downloads. 


Operations  with  a Replicated  File  Protocol 


Space-ground  data  operations  require  no  manual 
scheduling  and  supervision.  Projects  manage  data 
processing  over  the  Internet. 

I Satellite  wifh  on-board 
\.  I data  and  command  files 


File  Replication 
between  space  and 
ground  during 
intermittent  contacts. 


Virtual 

Satellite  I 

Accessible 

24/7  from  Internet 


Internet  Access  to  Files 
via  FTP,  etc. 


Files  Replicated 
to  and  from  the  Satellite 
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Fundamental  File  Exchange  Operation 


SAFE  copies  files  and  copies  them  successfully  even 
over  intermittent  connections  with  a high 
bandwidth*delay  product  and  high  bit  error  rate. 

The  copy  operation  is  connectionless  - there  is  no  time 
lost  establishing  and  maintaining  TCP  connections. 


Replication 
, Client 
[(directs  copy  step; 


Replication 

Server 

(replies  to  client)  j 


Secondary  File 
Copy  - Read  Only 


Primary  File  - 
Read  and  Append 


Ground  Station  Acts  As  Gateway 


Each  connection  passes  through  the  ground  station, 
which  acts  as  an  intermediate  connection  point. 


Satellite 


Ground 

Station 


Project 


RF  Segment 


Internet  Segment 
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Multiple  Ground  Stations  and  Destinations 


A satellite  may  connect  with  multiple  points  on  the 
Internet,  e.g.,  the  scientists  at  one  location  and 
spacecraft  bus  engineers  at  a second. 

Moreover,  a satellite  may  use  several  ground  stations 
at  different  points  in  its  orbit.  Conversely,  a ground 
station  may  serve  several  satellites  in  turn. 


Ground 

Stations 

X]> 


RF  Segment 


o 


Internet  Segment 


Engineering 


Demonstration  of  SAFE 


Internet 
(real  thing} 


PI  Workstation 
(SparcStation) 


& 

t 


RF  (wired  serial  link) 


Ground  Stations 
(Intel  PC) 


Satellite 

(laptop) 


The  demonstration  simulates  a scientist  accessing 
instrument  data  and  sending  commands  via  file 
replication. 

* Satellite  instrument  writes  data  to  onboard  file  which  is 
automatically  replicated  to  the  scientist’s  workstation. 

* Scientist  writes  instrument  commands  to  local  file  which  is 
replicated  to  satellite. 
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Testing  SAFE 


Purpose: 

• Run  file  transfers  with  realistic  light-travel-time  delays 
and  bit-error  rate  and  study  the  effect  on  the  data 
transfer  rate. 

Equipment: 

• Provided  by  the  IPIC  project  (TCP-over-satellite  test 
suite). 

■ Satellite  Modems  for  IP  are  COTS  but  not  space- 
qualified. 

• FYI,  we  are  using  PC  to  play  the  satellite  role  but  IPIC 
runs  a single-board  embedded  computer  for  better 
realism  during  TCP  tests. 


PC  playing  ^pa  f 

satellite  role  modem 


Channel 

simulator 


Space 

modem  SparcStation 
playing  ground 
station  role 


Lessons  Learned  from  Implementation 


The  low-cost  operational  scenario  is  realistic  and  easy 
to  implement  with  the  automatic  file  exchange  system. 

UDP  is  reasonably  effective  - on  a par  with  other 
alternatives. 

Congestion  control  is  essential  but  troublesome. 

* Congestion  control  is  built  into  TCP,  but  TCP  assumes 
all  packet  loss  is  due  to  congestion  and  the  control 
overreacts  when  packets  are  lost  due  to  line  noise  and 
data  drop-outs. 

* No  congestion  control  built  into  UDP  - the  nodes  can 
saturate  routers. 

* Congestion  control  is  built  into  the  file  exchange 
software  of  SAFE  and  has  been  optimized  for 
connections  that  have  line  errors  as  well  as  congestion. 

* Optimization  for  a noisy  space-link  connected  to  a 
congested  Internet  is  a difficult  problem  that  needs 
further  research  - or  better  - an  avoidance  mechanism. 


132 


Feedback 


The  implementation  has  been  demonstrated  for  many 
engineers  - who  had  important  comments: 

* The  key  impediment  is  the  lack  of  space-qualified 
hardware  that  supports  any  commercial  network 
protocol. 

* Many  existing  satellites  systems  have  an  uplink 
bandwidth  that  is  too  small  to  allow  an  error- 
correcting  protocol  of  any  kind.  Tradition  is  slow  to 
change. 

* There  is  an  important  type  of  mission  cannot  be 
accommodated  by  an  Internet  connection  because  the 
required  bandwidth  during  a pass  is  too  high.  The 
Internet  bandwidth  is  adequate  for  the  average  data 
rate  but  not  the  peak  bandwidth  during  a pass. 


Future  Initiatives 


Create  Opportunities  for  Use  in  Space 

* Need  to  proselytize  for  IP  so  that  there  are  customers 
for  commercial,  space-qualified,  IP  hardware. 

Specification  of  SAFE 

* leading  to  an  acquisition  of  an  implementation  from  a 
commercial  vendor  who  currently  markets  similar  SW 
(any  vendor  with  NFS  or  RPC  protocols). 

Small  systems  demonstration  to  show  feasibility  for 

very  small  satellites. 

* Current  demonstrations  use  486  PCs. 

* Considering  implementation  for  single-board  VxWorks 
computer. 

* Considering  demonstration  on  palmtop  computers. 

Applications  with  high  bandwidth  requirements 

* low  priority  - imaging  sciences  tolerate  packet  losses. 

* no  “simple”  solution,  see  “Details” 
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Contact  Information 


Paul  L.  Baker  and  James  Maxwell  Repaci 
Global  Science  and  Technology,  Inc. 

6411  Ivy  Lane,  Greenbelt,  MD  20770  USA 
301-474-9696 

James  L.  Rash 

Advanced  Architectures  and  Autonomy  Branch 
Code  588 

NASA  Goddard  Space  Flight  Center 
Greenbelt,  MD  20771 
301-286-5246 

We  thank  David  Sames  for  his  support  and  contributions  to 
this  work.  He  has  recently  left  the  project. 

Web  Sites: 

Global  Science  and  Technology:  http://www.gst.com 
Project  Working  Papers:  http://abita.gst.com/node.htm 
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File  Exchange  for  Satellite  to  Ground 
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File  Exchange  for  Ground  to  Satellite 
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The  satellite  continually 
requests  command  data  from 
the  ground.  During  a pass, 
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Basic  Gateway  Functions 


Upward  Packet  Gateway: 

■ Identify  packet  as  intended  for  satellite.  (Use  port  number  and 
optional  security  verification) 

• Convert  to  space  link  format  (if  different)  and  forward. 

Downward  Packet  Gateway: 

• Convert  to  IP  format  (if  different). 

• Insert  IP  address  of  gateway  as  source  address  of  packet. 

• Forward  packet  to  recipient’s  address  on  Internet. 

Packet  conversions 

• None  required  if  satellite  link  uses  IP  Modems. 

• Generally  need  to  add/remove  IP  headers  if  IP  was  not  used  on 
the  link  to  the  satellite. 


Mobile  IP  for  SAFE 


Problem: 

* The  satellite  connects  to  the  Internet  at  the  ground  station 
and  must  use  a local  IP  address. 

* The  satellite’s  IP  address  changes  from  one  ground  station  to 
another. 

' Future  enhancements  to  IP  protocol  have  been  slow  to  arrive. 

Interim  solution 

* Ground  station  applies  local  address  to  packets  from  satellite. 

* The  file  server  in  the  Mission  computer  notifies  the  replication 
application  when  it  learns  the  current  IP  address  of  the 
satellite. 
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Satellite  Telemetry  & Command 
Using  Big  LEO  Mobile 
Telecommunications  Systems 


Fred  Huegel,  NASA  Goddard  Space 
Flight  Center 

Code  568 


June  2,  1998 


Objective 


Use  Commercial  Global  Satellite  Mobile 
Telecommunications  Systems  (Big  LEOs)  to  provide 
Telemetry  and  Command  Services  to  user  satellites  in 
LEO 

■ The  user  spacecraft’s  transceiver  would  be  a space  qualified 
version  of  the  systems  User  Terminal  (mobile  phone) 

Globalstar,  ICO  and  Iridium  have  been  studied 
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• Provide  real  time  contact  to  LEO  user  satellites  with  a 
simple  phone  call 

• Provide  the  capability  for  the  satellite  to  “phone  home” 

• Command  and  telemetry  data  rates  of  8K  bits/sec 

■ Higher  rates  with  data  compression 

• At  least  one  5 minute  contact  per  orbit 

• Small,  low  power,  low  cost  transceiver 

• Simple  omni  antenna  system 

• Secure  link 


Rational  - Make  use  of  the  Billions  of  $ of 
privately  funded  infrastructure  to  provide  : 


Reduced  Mission  Communications  System 
Cost 

■ Reduces  or  eliminates  the  cost  of  ground  stations  and 
associated  infrastructure 

■ Eliminates  the  need  for  frequency  assignments 

■ Low  cost  transceiver,  small  size,  low  mass  and  low  power 

Flexibility  in  Science  Operations 

■ Event  monitoring  and  immediate  reporting 

■ Quick  look  data  evaluation 

■ Several  Contacts  per  orbit  possible 

■ Real  time  access  to  user  satellites  from  remote  locations 
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Capabilities  - Iridium 


The  fairly  low  constellation  orbit  (780  KM)  precludes 
significant  coverage  of  user  satellites 

■ In  general  contacts  are  very  short  with  large  coverage  gaps 

■ Polar  orbiting  user  satellites  are  an  exception  - adequate  coverage 
is  available  in  this  case  due  to  co-orbiting  of  the  user  sat  with  the 
constellation  satellites 

■ Data  rates  limited  to  2400  bits/sec 

Possible  use  of  crosslinks  has  been  investigated 

■ Could  provide  excellent  coverage  and  Mbit/sec  data  rates 

■ User  Satellite  would  “take  over”  the  intersatellite  link 

■ Technically  feasible  but  not  deemed  operationally  feasible  by  Iridium 


Capabilities  - ICO  Global 


• Excellent  coverage  for  orbits  up  to  900  km 

■ One  10  to  30  minute  contact  per  orbit  using  only  one  gateway 

■ Optimal  coverage  at  52°  inclination 

• Front  end  Doppler  compensation  required 

• Data  rates  limited  to  2400  bits/sec 


Capabilities  - Globalstar 


Good  coverage  for  orbits  up  to  600  Km  with 

inclinations  up  to  57° 

■ The  lower  the  orbit  the  better  the  coverage.  Optimal  coverage  at  52° 
inclination 

■ Better  than  one  contact  per  orbit  at  400  km  using  4 gateways 

■ contacts  range  from  5 to  18  minutes,  the  average  is  1 1 minutes  at 
400  Km,  52°  inclination 

No  front  end  Doppler  compensation  required 

■ Range  rate  between  Globalstar  satellite  and  user  satellite  no  greater 
than  that  experienced  for  a user  on  the  Earth’s  surface  90%  of  the 
time 


Globalstar  (Continued) 


• Data  rates  up  to  8 Kbits/sec  possible 

• At  an  orbit  of  400km,  52°  inclination 

■ Total  contact  time  per  day  is  about  264  minutes 

■ Total  downlink  per  day  is  127  Mbits 

■ Average  outage  time  is  56  minutes 

• Initial  feasibility  study  with  Globalstar/Space  Systems 
Loral  completed  12/96 

■ System  issues  identified 

■ Link  analysis  performed 

■ No  show  stoppers  identified 
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Globalstar  Link  Analysis 


Assumptions 

■ Omnidirectional  coverage  required 

■ Coverage  over  full  Globalstar  FOV  (108°) 

■ Eb/No  requirement  as  specified  in  FCC  filing 

■ Maximum  link  range  used  for  a user  satellite  in  a 300  Km  altitude 

■ Single  Globalstar  in  view  (no  signal  combining) 

■ Maximum  transmission  rate  of  9.6  kbps 

■ On  average  during  a pass  0 dB  of  additional  dynamically  supplied 
additional  power  required. 

Link  closes  under  the  following  conditions 

■ Transmit  switch  used  rather  than  splitter 

■ Low  loss  cabling  used  (Gore  ~ 0.2dB/Ft) 

■ Low  noise  amplifiers  are  located  at  the  antennas 


Globalstar  Issues 


Protection  of  Radio  Astronomy  Sites  (RAS) 

■ Sensitive  in  the  1610.6  MHz  to  1613,8  MHz  range  (Globalstar  return 
link) 

■ Requires  operation  at  the  upper  end  of  the  assigned  L Band 
frequency  range  as  well  as  the  use  of  a transmit  band  reject  filter 

■ Or  restrict  operations  when  near  an  active  RAS  site  (reduces 
potential  contact  opportunities) 

Location  information  required 

■ Normal  call  handling  procedures  require  the  location  of  the  user 

- This  is  normally  determined  by  the  Globalstar  system  but  will  not  work 
for  Space  applications 

■ Location  can  be  determined  by  on  board  ephemeris  or  GPS  and 
entered  into  the  transceiver 
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Flight  Transceiver 


• Derivative  of  fixed  User  Terminal 

■ easily  adaptable  for  position  input 

■ Control  and  data  interface  to  the  spacecraft  C&DH 

• Size  and  weight  are  driven  by  the  band  reject  fitter 

■ Approximate  size  8 by  6 by  3 inches 

■ Approximate  weight  is  7 pounds 

• Power 

■ Standby,  1 .5  watts 

■ Transmit,  20  watts 


Security 


• Gateway  to  User  Satellite 

■ CDMA  inherently  secure  (spread  spectrum  system) 

■ Encryption  of  traffic  channels  part  of  Globalstar  baseline 

• Ground  segment 

■ Call  acceptance  filtering  by  ground  system  blocks  unauthorized  calls 

■ Phone  numbers  can  be  re-assigned  if  necessary 

■ Use  of  unlisted  phone  numbers 
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Conclusions 


• Feasibility  study  with  Globalstar  indicates  that  spacecraft 
command  and  telemetry  through  commercial 
telecommunications  satellite  constellations  is  feasible  with  little 
or  no  modifications  to  the  system  architecture 

• The  user  would  connect  to  their  spacecraft  via  telephone/modem 

• Frequent  contact  opportunities  would  be  available 

• Data  rates  are  limited  but  adequate  for  command/telemetry  and 
quick  look  science 

• Further  studies  of  the  Globalstar  and  ICO  systems  are  needed  to 
better  define  the  capabilities,  limitations,  and  system  impacts  of 
the  Space  Mobile  Service 


Key  Benefits 


Facilitator  for  low  cost  LEO  missions  such  as 
University  Explorers  (UNEX),  Small  Explorers  (SMEX) 
and  others 

■ Could  provide  significant  savings  per  mission 

■ Users  pay  only  monthly  access  fee  and  per  minute  charges 
Provides  flexibility  and  simplification  in  mission 
operations 

■ Enhanced  access  to  spacecraft 


\section\  Phone  Link2-97 


1- 


Session  3 

Architectures  and  Network 
Simulations 


Page  intentionally  left  blank 


NORTEL 

NORTHERN  TELECOM 


Satellite  System  Architectural 

Issues  for: 

Broadband  Interactive 
Multimedia  Communications 

Gary  Johanson 
Chief  Architect 

Nortel  Satellite  Network  Solutions 


June  2.  1998 


Gary  Johanson 


Topics 


N&RTEL 

NORTHERN  TELECOM 


• Driving  Forces 

• What  is  Webtone?  What  is  Satellite  Webtone? 

• Terrestrial  and  Satellite  Comparison 

• Network  Dynamics 

• Research  Topics 

• Planning  and  Tools 

• Challenges 


June  2.  1998 


Gary  Johanson 


Internet  / Intranet  Growth 
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Number  of  users  on  the 
(M)  world  Wide  Web 


1995  1996  1997  1998  1999 

Source:  International  Data  Corporation 

• Intranet  servers  will  outsell  Internet  servers  by  more  than 
10  to  1 by  the  turn  of  the  century 

• Intranet  market  will  grow  to  $20  billion  by  the  year  2000 

June  2,  1998  GaryJohanson 
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Internet  Users  (Worldwide) 
Users  (Mi 
1996  60 

2001  300 

Source:  Pala  Communications  Sep-97  » 


Computers  Connected  to  Internet 

Units  (Ml 

1996 

48 

1997 

82 

2001 

268 

Source:  Computer  Reseller  News  Sep-97 

Internet  Users  (Worldwide) 

Users  (Ml 
1997  60 

2001  175 

2007  1,000 

Source:  Washington  Technology/1  DC  Oct-97 


Fortune  1000  Companies  Planning  to 
Implement  IP  Telephony 
% 

1997  12% 

1998  29% 

1999  42% 

2000+  69% 

no  plan  31% 

Source:  Computer  Reseller  News  Oct-97 


Spending  on  Intranet  & Extranet 
Products  & Comm  Services 
US  S Billion 
1996  19 

2000  55 

Source:  Beyond  Compuliog/Zona  Research  Oct-97 
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bundled  through  a single  telecom  or  IS 
vendor 
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Satellite  Broadband  Market  Forecasts  NORTEL 
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• Broadband  Satellite  Systems  investments  in 
Space  and  Ground  Segments 

- $76B  over  the  next  10  years 

• Broadband  Satellite  Service  Revenues 

- $350B  over  the  next  10  years 

• Broadband  Satellite  Data  Subscribers 

- 36  million  over  the  next  10  years 

• Broadband  Satellites  Deployed 

- 505  satellites  over  the  next  10  years 

Source  : Pioneer  Report  1997 

June  2,  1998  Gary  Johanson 
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Public  Networks 

Early  Stages 

June  2,  1998 


Gary  Johanson 
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Evolution  to  Multimedia  NORTEL 

NORTHERN  TELECOM 


Telecommunications  Computin  g 


Internet 


Gary  Johanson 

“Webtone”  NORTEL 

NORTHERN  TELECOM 


TODAY 

TOMORROW 

Internet  Access 

“Webtone” 

ACCESS 

Cumbersome 

Method/Devices 

Easy  Access 

CAPACITY 

Not  Dynamic 

Dynamic/Flexible  On- 
Demand 

QUALITY 

Intermittent 

PSTN  Quality 

SECURITY 

Intermittent 

Security  Guaranteed 

ECONOMIC  EQUATION 

Questionable 

Economics 

Viable  Business  Cases 

Private  Networks 

Service  Capability  to 
Meet  Specific  Needs 
and  Priorities 

Enhanced  Flexibility 

Public  Networks 

Early  Stages 

“Webtone” 

June  2,  1998 

Dial  tone 


June  2,  1998 


Gary  Johanson 
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Supporting  Webtone  Demand 


N&RTEL 

NORTHERN  TELECOM 


Access  Media  are:  T 

' • ■ - 7-i‘i 


c°mpeting  and  ,| 


complgrnentary 


Evolutiphary 

;¥v"  - 


- ^ 


' • Capital-intensive/*  j 

•■■■*  ■ : 

and 


No  single  solution^ 
will  help  all  users  3 


analog  modems 
ISDN 

Power  systems 
Cable  TV 

XDSL 

LMDS/LMCS 

Fiber  Networks 

VSAT 

C/Ku  terrestrial  return 
C/Ku  - Ka  return 
Ka  band  systems 

V-band  systems 


June  2,  1998 


10k  100k  1 M 10  M 100  M 1G  10  G 

Bandwidth 
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What  is  Satellite  Webtone?  N£?RTEL 

NORTHERN  TELECOM 


GEO^ 

MEO/  

LEO  * 


ip/ 


Network  Advantages 

• Ubiquitous  coverage 

• Instant  availability 

• Broadcast  data 

• High  capacity 
Ify  • Spot  beam  reuse 


IP/£... 


• Global  deployment 

• Low  latency 


Carrier  / ISP 

• Network  hub 
•VPN 

• Interconnection 

• Unserved  telecom 


LMDS 


June  2,  1998 


Business  SOHO 


• Inter/intranet  • Internet 

• Multimedia  • Multimedia 

• Global  networks  • Wideband 


Consumer 

• Internet/web 

• Entertainment 
Convergence 
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Fundamental  Dynamics  of  Networks  N£?RTE  L 

NORTHERN  TELECOM 


• Capital 

• Operations  & Maintenance 

• Advertising 

• Inter-connection 


• Blocking 

• Post  Dial  Delay 

• Voice  Quality 

• Bit  Error  rate 


Gary  Johansen 


Nortel’s  R&D  on  BSN 


NORTEL 

NORTHERN  TELECOM 


Hub/GW  Architecture  MM  Air  Interface  SAU 


Gary  Johanson 


153 


Major  Network  Design  Considerations 


N&RTEL 

NORTHERN  TELECOM 


w Traffic  Distribution  and  Load  Balancing 
»•  Traffic  Smoothing 
*•  Signaling 

* Resource  Management 
w Routing 

w-  Admission  and  Congestion  Control 
*-  Performance  Assessment 
»-  Number  of  Gateways  and  Their  Location 
End-to-End  Quality  of  Service  and  GoS 
•»-  Iland-off  Issues 
«►  Distribution  of  Services 
•*-  Distribution  of  Control 

Interfaces  to  Terrestrial  Networks 
*-  Cost  Analysis 


Satellite  Network 
Design  & Architecture 


Gary  Johanson 


Required  Planning  Capabilities 

. Total  Network  Optimization 


NORTEL 

NORTHERN  TELECOM 


Comprehensive 
Business  & Residential 
Database 


Target  \ 
Services 


Col:  Communily  of  Interest  . 

GoS:  Grade  of  Semico  * MarKef 

OoS:  Quality  of  Service  Estimator 

OBP:  On-Board  Processor 

OAM  : Operations,  Admin.  & Mtee. 

NCC  : Network  Control  Center 
NOC  : Network  Operations  Center 
OBNC  : On-Board  Network  Control  Center 


Services  Planning 
Market 

Characterization 
Revenue 
Estimation 
Beam  Sizing  and 
Placement 
Server/Gateway 
Placement 
Satellite  Network 
Architecture 


End-to-End 
GoS/QoS 

Satellite  Functionality 
Placement 
OBP  Functionality 
OBP  Switch  Architecture 
OAM  Issues 
Performance  Metrics 
CPE  Characteristics 


Business  Case 
& Strategy 


Customer 

Domain 


Gary  Johanson 
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Tool  Requirements 


N&RTEL 

NORTHERN  TELECOM 


Examples  of  Nortel  Tools: 

• Service  Planner 

• Traffic  Estimator 

• Market  & Service 

s Server/Gateway  Placement  Tool 

• Network  Planner 

• Tools  to  simulate  behavior  of  target  satellite  systems 

• Tools  for  multi-media  traffic  models,  node  models,  link  models,  and  satellite 
mobility  models 

• Tools  to  assess  end-to-end  QoS/GoS  and  subscriber  capacity  parameters  for: 

- variety  of  Call  Admission  Control  and  Routing  algorithms 

- variety  of  medium  access  algorithms 

- innovative  combinations  of  integrated  network  architecture 

- variety  of  transport  technology  (A  TM,  Frame  Relay,  TDM,  IP,...) 

• Tools  for  OA&M 


Gary  Johanson 

Main  Networking  Challenges 


N&RTEL 

NORTHERN  TELECOM 


Static  Architecture  Challenges: 

• Air  Interface:  uplink,  downlink,  ISLs 

• Functional  Partitioning:  on-board  vs.  on-ground 

• End-to-End  Resource  Management:  BOD,  CAC.  routing,  policing... 

• Service  and  Protocol  s Adaptation:  TCP, . . . 

• Performance:  billable  bandwidth,  end-to-end  QoS  and  GoS,... 

• Signaling  Protocol  Design  & Verification:  message  flows,  timing 

• NCC:  number,  location,  connectivity... 

• Dimensioning 

Mobile  Architecture  Challenges:  above  +: 

• Constellation  Design:  tear  drop,  coverage  areas,  ISLs 

• Satellite  Mobility  Effects:  path  length 

• Routing:  optimise  to  decrease  on-board  processing  and  storage  requirements 

• Handover 

Exception  Handling  Risk  Areas: 

• System  Reliability  and  Robustness 

• Availability:  assessment,  guarantees,  verification 

• Remote  Diagnostics:  protocols,  satellite  vs.  terrestrial  transport,  impact 
Network  Management: 

• Information  Architecture:  design,  test  and  validation 

Gary  Johanson 
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Internal  Program  Thrusts 


NORTEL 

NORTHERN  TEIECOM 


• Distribution  of  functionalities  among  network  elements  for  networks  including  satellites. 

• Architectures  for  LEO/MEO/GEO-bascd  BSN. 

• Impact  of  inclusion  of  satellite  in  multimedia  networks  including  QoS  and  performance  issues 
as  well  as  signaling. 

• Design  of  bandwidth  on  demand  protocols,  simulation  and  validation  of  their  performance. 

• Charging  and  dynamic  resource  control  associated  with  bandwidth  on  demand. 

• End-to-end  resource  management  to  provide  end-to-end  QoS  and  GoS. 

• Design,  optimization,  simulation,  and  performance  enhancements  of  routing  algorithms  for 
multimedia  traffic  over  satellite  (LEOs  and  GEOs). 

• ATM  over  satellite,  IP  over  satellite. 

• Performance  assessment  of  OB  switch  architecture. 

• Dimensioning. 

• Network  Management  & Control. 

• Adaptation  of  existing  standards  and  methodologies  to  adapt  to  satellite  segment  of  a global 
network.  Includes  signaling  (e.g.  Q2931). 

• Service  adaptation. 


Gary  Johanson 


Summary 


N0RTEL 

NORTHERN  TELECOM 


• Satellite  Webtone  is  coming 

- Webtone  attributes  are  a necessity 

- High  copnectivity 

- Multi-application,  multi-network 

• Many  new  opportunities  for  operators 
- old  and  new  for  new  services 

• Results  - a large  market  potential  on  a 
global  basis 

• Many  challenges  remain 


June  2.  1998 


Gary  Johanson 
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SIMULATION  OF  A NASA  LEO  SATELLITE  HYBRID  NETWORK 


Thomas  M.  Wallett*,  Vijaya  K.  Konangi**,  and  Kul  B.  Bhasin* 


‘Satellite  Networks  and  Architectures  Branch  “Department  of  Electrical  and  Computer  Engineering 
NASA  Lewis  Research  Center,  Mall  Stop  54-5  Cleveland  State  University 
Cleveland,  Ohio  44135  Cleveland,  Ohio  44115 

(216)  433-3673  Thomas.M.Wallett@l  erc.nasa.gov  (216)  687-2588  Konangiacsvax.csuohlo.edu 
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OBJECTIVE 


Investigate  the  performance  of  TCP/IP  in  a hybrid  network  consisting 
of  a global  terrestrial  network  and  a LEO  satellite  by  simulation. 
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Satellite  LEO  - circular  orbit  at  650  km  altitude 
52  degrees  inclination 
FTP  server 

Transmission  and  reception  at  9S0Q  bps 

Houston,  United  States 

Central  node  of  a star  topology 
FTP  client 

Terrestrial  transmission  and  reception  at  DSO  (64  kbps) 
Radio  transmission  and  reception  at  9600  bps 

Seoul,  South  Korea;  Canberra,  Australia;  Toulouse,  France; 
India;  Saudi  Arabia;  Central  Africa;  Brazil 

Above  terrestrial  nodes  connected  to  Houston 
Terrestrial  transmission  and  reception  at  DSO  (64  kbps) 
Radio  transmission  and  reception  at  9600  bps 


2 JUNE  1998  SATELLITE  NETWORKS:  ARCHITECTURES,  ...  AM_ 
SS8  APPLICATIONS,  AND  TECHNOLOGIES  CLEVELAND 
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CONCLUSIONS 

• The  satellite  transmitter  average  throughput  saturates  for  large  files. 
(-  3500  bps) 

• Houston  receiver  average  throughput  inconclusive. 

(radio  reception  only) 

• Frequent,  large  End-to-end  delays  for  large  files. 

(small  % increase  for  file  size  increase) 

• Infrequent,  small  End-to-end  delays  for  small  files. 

(large  % increase  for  file  size  increase) 

• Queueing  delays  at  the  terrestrial  nodes  are  not  significant. 

• TCP  slow-start  algorithm  degrades  the  performance  for  large  files. 


Page  intentionally  left  blank 
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Multi-Media  Traffic  Modeling  and 
End-to-End  QoS  Evaluation  Tools  for  Satellite  Networks 


Evan  Geraniotis 

Center  for  Satellite  and  Hyrbid  Commun.  Networks 
Institute  for  Systems  Research 
University  of  Maryland 
College  Park,  MD  20742 

Tc-f  - 301-405-3^6 
FA*--  3ol-31*t-Wl 
e-weCif'  evrtge&s  0 «vi«|.uwd  .eolu 

V I ) 


Modern  Network  Characteristics 


• Substantial  network  size 

• Complex  network  architecture 

• Multi-media  traffic 

• distinct  statistical  features 

• different  quality  of  service  (QOS)  requirements 

• high  data  rates 

• Network  protocols  must  guarantee  end-to-end  QOS  for  all 
traffic  types 

• Mixture  of  transport  (switching)  modes  present 

• circuit-switching 

• packet  switching/cell  switching  (ATM) 

• hybrid  switching 
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Unique  Features  of  Approach 


• New  Class  of  Accurate  and  Flexible  Models  for  Multi-Media  Traffic 

• Markov-Modulated  Rate  Processes  (MMRP) 

• Fractal  Renewal  Processes  (FRP) 

• Characterization  of  End-to-End  QOS  via  Accurate  and 
Time-Efficient  Approximations  and  Confidence  Intervals 

• QOS  for  circuit-switched  networks 

• QOS  for  packet-switched  and  cell-switched  (ATM)  networks 

• QOS  for  hybrid  switched  networks 

• Efficient  Protocol  Design  Based  on  Optimizing  End-to-End  QOS 

• connection  admission  control 

• dynamic  bandwidth  allocation 

• routing/congestion  control 

• switching/buffer  management 


High  Data  Rate  Satellite  Networks 


Approach 

• Apply  multimedia  traffic  modeling  tools  to  traffic  types  and  data  rates 
of  interest  (images,  video,  data,  voice)  to  specific  HDR  applications 

• Use  satellite  orbit  modeling  tool  to  model  dynamics  of  intersatellite 
links 

• Use  tools  for  QoS  fast  evaluation  for  comparisons  of  alternative  on- 
board switching  architectures 

• Use  tools  for  QoS  fast  evaluation  for  end-to-end  performance  measures 
(delay,  throughput,  blocking  rate,  dropping  (loss)  rate)  and 
performance  measures  at  intermediate  nodes  (buffer  overflow  rate, 
queuing  delay,  average  queue  size,  queue  length  distribution) 

• Use  sensitivity  analysis  tools  for  fast  evaluation  of  variations  of  QoS 
w.r.t.  traffic  loads,  link  capacities,  buffer  sizes 

• Use  optimization-based  techniques  and  efficient  simulation  for  trade- 
off analysis  and  systems  engineering.  < 
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Generic : 


Tool  Sets 


Circuit-switched  Multi-media  Networks 

Virtual  Circuit-switched  Multi-media  Networks 

(connection-oriented  ATM  traffic) 

Cell-switched  Multi-media  Networks 

(connectionless  ATM  traffic) 

Packet-switched  Multi-media  Networks 

(datagram-type  traffic) 

Specialized  by  Application : 

Networks  of  LEO,  MEO  and  GEO  Satellites 

Wireless  Multi-media  Networks  (indoor,  WLANs,  cellular  and  PCS) 

Wireline  Multi-media  Networks  (B-ISDN,  ATM,  FDDI,  DQDB) 

. Hybrid  Networks 


Tool  Modules 


Modes  of  Tool  Operation: 


Stand  Alone 

Umd  with  Simulation  Tooh  (e.g.,  OPNET,  HONES) 
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Multi-Media 
Traffic  Lift: 

AfMfewyCMTMBc 

AMnqjgniWk 

Vafca 

VUa 

Dm 


Statistical  Featom:  Markovian  Models  Matched 

Amnmam  to  Parameter!  and  Functions: 


State  Diagram  A Sample  Traffic  Process 

Characteristics  of  an  On-Off  Source 


Parameters  Matching 


Modeling  of  Actual  Data  Traces  Using  On-Off  Sources 
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Summary  of  Simulation  Results  for  On-Off  Source  Modeling 


Multi-Media  QoS  Evaluation  Tool 

— and-to-end 
— Intermediate  node 


modeling  tools 

Ilnk-ln-lwlatitNi 

* — 

reduced-load 

fixed-petal 

QoS  evaluation 

approximation 

Iteration 

protocol  dexlgn 
A optimization  looti 

fan  protocol 
evaluation 


Knaptack  approx,  technique 
Paacal  approx,  technique 
State  aggregation  technique 
Folding,  Onaamann  algorithms 


Porfbrmanoe  Measures 


end-to-end 


Mocking  probability 
dropping  (km)  probability 


intermediate ' 
node 


buffer  overflow  (lots)  probability 
queueing  delay 
average  queue  length 
queue  length  distribution 
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Sensitivity  Analysis  Tool 

end-to-end 

— — Intermediate  node 


Compute  derivaiim  of  QoS  w.r.t.  traffic  loads 

- — link  cepacitiei 
— model  penmeten 


protocol  deiij* 

* optimization  looli 

fact  protocol 
sensitivity  dialysis 

I 

gnphict 


Tools  for  Protocol  Design  and  Optimization 


QoS  EvahaarioaToeb 

Conttraint  Optimization  Routinro 

(linear  programming.  nottlinaar  programming) 

Sensitivity  Analysis  Tooit 

Dynamic  Programming  Routinat 

(value -itantion  algorithm,  policy-iteration  algorithm) 

* 

• 

Optimized  protocoli 
— ■•>■ 


List  of  Potential  Applications: 


^ Ad  miuion  Control 
BandwddtfuMjeca^ 
Routing 

Buffer  Mana|temem 
Switch  Design 
Flow  Control 


Multicasting 

Multiple  Satellite  Diversity  U 
Satellite  Hendoff 

Hierarchical  Overlays  and  Handoffi 
Jnterteeuntl^P^TN^Cdluhr  atydPCS, 
Parallel  Multi-channel  Demodulation 
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• Voice  and  video  calls  are  transported  in  a connection-oriented 
fashion  using  virtual  circuits. 

• Packet  switching  is  used  for  data  traffic. 

• Priorities  of  voice  and  video  traffic  are  assumed  to  be  higher  than 
that  of  data. 


• Values  of  the  blocking  probabilities  for  voice  and  video  traffic, 
normalized  voice  processing  loads,  video  rate  dropping  probabilities, 
and  data  queueing  probabilities  are  obtained  using  a time-efficient 
approximation  through  the  reduced-load  method. 

• The  bandwidth  allocated  to  a video  call  and  the  step  size  of  a 
voice  virtual  path  are  varied. 


• The  performance  measures  of  the  network  can  thus  be  controlled 
and  optimized. 


Approximations 

Exact  Analysis 

Monte  Carlo 

Complexity 

O(10e»|P||£|) 

0(yV(A/  + 3)|J>H£|) 

Time 

1 -2  minutes 

Prohibitive 

15  30  CPU  hours 

Tallin  1:  Complexify  Analysis 

(|7’|  - number  of  paths.  \C\  inmilmr  of  links.  M video  model’s  parameter.) 
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Paradigm  2 (continued) 


«M*»  CwnHM.rfrirfciBi.iirf AH— «H»»— t^»ilil»ihr Vd—Wfc— Or. 

*rtoOMMlfcOHWfc)tt.l[MBrfAp*HHMfc.fctNHMHiil%MlA 

\WMMMrfcwW.4#).M,fcwrfVfc.rnkfci«t-(il>.>Ii)i 

fcfc%I«(l.l,M).M«rfWaODNrM(>r.(l>l). 


MIMIT 

IHTH) 


t.miM 


[TltjrzrjirrBiKaigsiroii 

laOIMinXilM 

■MMM|n^TTnTjnj 

■usmi 

Til  ■— 


Mb)  Cirfirlw  rflrfrfi..r.rfUH  ItoW  llrflB  MfclfcBrfOHiliH 
by  Opll«rl.l.t  >h«  >■»>■*  Am  r ■!■  ill.,  dwt  TW  AHmwH*.  fcMt>htg  fcrtfcrf^fcfa. 
CHb  hr  H.l.n>  hr  Dpt.  l.b. 

WHm  AHMty  (beta*  #/<•  ♦ f\ ■ 44  , VmW  rf  VHm  htt  Mata,  i a (1,*.  M). 

Cr.w>r  f a (l.f.T.I) , Aktmlli.  iwlha  Orhr  KUUU|)| 

VMtar  rf  OD  Mr  UH  ft  a (I.1K  V«Mr  rf  Drf.  OO  Irfr  larf  £*  ■ (4.1). 


Characteristics  of  Internet  Traffic  for 
Planning  Satellite  Networks 


Bachittar  Singh  Sembi 

Brian  Armbruster 

VISTAR  Telecommunications  Inc. 


Sembi,  B.S.,  Armbruster,  B 

Background 


VISTAR- 


• The  economics  of  a consumer  satellite  system  heavily 
depends  upon  the  number  of  people  sharing  a fixed 
amount  of  satellite  bandwidth  and  the  associated  cost 

• The  bandwidth' available  to  each  active  Internet 
customer  determines  the  acceptability  of  the  service 

• Most  Internet  traffic  numbers  are  available  at  the  core 
networks  and  not  at  the  individual  access  point  to  the 
network 

• We  need  to  improve  our  understanding  of  the 
bandwidth  required  by  an  individual  user  to  evaluate 
if  a satellite  offering  is  viable 

Sembi,  B.S.,  Armbruster,  B VIST 
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To  improve  our  understanding  of  the  bandwidth 
requirements  for  potential  Internet  services  by 
the  user: 

- Search  of  the  current  literature 

- Measure  the  traffic  patterns  of  individual  users 

- Estimation  from  the  consensus  process  of 
“Experts” 


Sembi,  B.S.,  Armbruster,  B 


VI£JAR- 


Internet  based  Communication  Services 

Various  Internet  based  communication  services  need  to  be 
evaluated  to  determine  overall  capacity  requirements  of  an 


individual  user,  for  example: 

100 

• Email 

• WWW 

• Tele-education  : 

• Tele-banking  : 


HTTP  Traffic  an  Percentage  of  Total  Traffic 


WWW  (http) 
traffic  has  grown 
from  0 to  70%  in 
about  3 years. 
Internet  traffic  is 
predominately 

WWW 

http://www.nlanr.net/ 

NA/leam/daily.html 


fSSSSSSSSi 


;s;sssss??ssSsi||ssss?ss 
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Need  to  grasp  WWW  traffic,  which  is  the  key  indicator 
with  most  traffic  volume  today 
Focus  on  WWW  (http)  as  a first  step 


Sembi,  B.S.,  Armbruster,  B 
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Internet  growth  patterns 


pattern  is  unknown  - a 
key  requirement  for 
satellite 

# of  Customers 


Prediction  are  subject  to 
uncertainty  such  as: 

- Bandwidth  prediction  as 
services  evolves 

- Technology  evolution 
impacts 

- Role  of  Internet  as 
compared  to  TV,  phone 

- Can  the  cost  be  cheap 
enough  for  mass  market 


Key  Information  for  Access  Service  Providers  is  the  bandwidth  per  active 
subscriber  (“logged  on”)  in  each  direction  in  the  busy  hour 


Sembi,  B.S.,  Armbruster,  B 


VIjjJAR- 


• Satellite  is  a shared 
medium  - Cost  amortised 
over  B/W  used 

• DSL  has  dedicated 
facilities  to  customer 


Sembi,  B.S..  Armbruster,  B 


VIJjJAR- 
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Search  from  the  Current  Literature 


• Most  published  statistics  about  the  Internet  traffic 
are  measured  at  the  core  of  the  network 

• No  easy  way  to  determine  an  individual  usage  from 
the  core  statistics 


• However,  the  search  found: 

- One  recent  study 

- Provisioning  information  from  a Canadian  ISP 
service  provider 

- The  telco  provisioning  guidelines  for  ISP  service 
providers 


Sembi,  B.S.,  Armbruster,  B 


Modelfor  Internet  Browser  Traffic 

Assumptions  for  a Browser  model 

- Active  users  model 

- Response  file  of  20  Kbytes  | [_J  [J  |_ 

- Mean  Inter-request  time  of  20  secs  I Idle  User  ^ Ac,ive  User  ^ 

- Request  size  is  400  bits 

- Non-Modem  access  to  Internet 


Traffic  is  20bps  (w/o  protocol  o/h)  from  an  active  user 
Traffic  is  8kbps  (w/o  protocol  o/h)  to  an  active  user 

Traffic  rate  experienced  by  ISPs  today  is  2 - 4 kbps 


Saulnier  E.T,  Esposilo  J,  et  al:  Ka-band  Satellite  communications:  The  issues  attending  provision  of  two-way 
consumer  services  - 3rd  Ka-band  utilization  conference.  Sept  97 

Sembi,  B.S.,  Armbruster,  B 


VI^EAR- 
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ISP  Service  Providers 


Canadian  ISP 
provisioning 
(>50k  Subs) 

Total  Modems  bw  ig  |0:] 
Total  Backbone  bw 

# of  Customers  js  16;, 

# of  Modems 


US  West  guidelines 
for  an  ISP 


Total  Modems  bw 
Total  Backbone  bw 


«* 


# of  Customers 

# of  Modems 


is  10:1  to  20:1 


Average  b/w  to  a subscriber  is  180  bps 
Average  b/w  to  an  active  user  is  2.8  kbps 


Average  b/w  to  a subscriber  is  288  - 576  bps 
Average  b/w  to  an  active  user  is  5.7  kbps 


• Access  limited  to  50-60  Hrs/month 
for  fixed  price  (adequate  for  most 
users) 

• No  busy-tone  provisioning  policy 


• Ratio  of  10:1  recommended  for 
high  quality  ISPs 

• These  numbers  are  from  a US 
West’s  perspective,  who  sell 
bandwidth  to  ISPs 


Sembi,  B.S.,  Armbraster,  B 
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Vistar  Measurement  of  User  Traffic 


• A CNA  personal  traffic  monitor  tool  was  used  to 
monitor  the  LAN  traffic  for  a number  of  users  on 
Vistar’s  LAN 

• All  users  are  business  users  who  may  use  Internet 
during  day  time 

• CNA  traffic  monitor  is  a software  tool  which  runs 
on  a PC  and  is  primarily  designed  to  monitor  the 
performance  of  the  LAN. 

• No  external  hardware  monitor  was  required  for 
tapping  the  LAN 
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• The  number  of  bytes  to  and  from  a specific  user 
for  a period  of  time  in  10  minutes  samples. 

• The  objective  here  is  not  to  measure  instantaneous 
peaks,  but  total  data  over  a period  of  time 

• This  data  includes  the  Internet  access  and  all  other 
activity  on  the  local  LAN,  such  as  printing,  file 
server  access 


Sembi,  B.S.,  Armbruster,  B 
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Measured  Statistics  for  Average  User 


Summary  of  Average  Statistics  collected  - For  all  the  active  user  for  each  day 
including  Downloading 


Average  bps_Rx 
Average  bps_Sn 
Total  KBytes_Rx 
Total  KBytes_Sn 


21  -Oct-97 
564.39 
274.82 

2,201.13 
1,071.80 


20-Oct-97 

465.81 

268.30 

1,816.00 

1,046.00 


7-Oct-97 

947.01 

483.09 

3,622.33 

1,847.83 


2-Oct-97 

2,108.10 

246.68 

7,431.04 

869.53 


Average 

1,021.33 

318.22 

3,767.63 

1,208.79 


[Summary  of  Average  Statistics  collected  - For  all  the  active  user  for  each  day 
[excluding  Downloading  


Average  bps_Rx 
Average  bps_Sn 
Total  KBytes_Rx 
Total  KBytes_Sn 


21 -Oct-97 
564.39 
274.82 

2,201.13 
1,071.80 


20-Oct-97 

465.81 

268.30 

1,816.00 

1,046.00 


7-Oct-97 

813.12 

436.56 

3,110.18 

1,669.86 


2-Oct-97 

484.66 

190.13 

1,708.44 

670.20 


Average 

582.00 

292.45 

2,208.94 

1,114.46 
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Measured  Statistics  for  Heaviest  User 


— 

Summary  of  Statistics  collected  - User  with  highest  peak  in  each  day  including 

Downloading 

...  -. 

L. 

21 -Oct-97 

20-Oct-97 

7-Oct-97 

2-Oct-97 

Average 

Peak  kbps 

8.20 

9.51 

30.11 

49.47 

24.32 

Average  bps_Rx 

738.00 

• 689.00 

1,348.00 

5,354.00 

2,032.25 

Average  bps_Sn 

187.00 

331.00 

622.00 

359.00 

374.75 

Total  KBytes_Rx 

2,878.00 

2,690.00 

5,158.00 

18,876.00 

7,400.50 

Total  KBytes_Sn 

731.00 

1 ,291.00 

2,382.00 

1,268.00 

1,418.00 

j 

[Summary  of  Statistics  collected  - User  with  highest  peak 

in  each  day  excluding 

(Downloading 

“ ■ _ 

21 -Oct-97 

20-Oct-97 

7-Oct-97 

2-Oct-97 

Average 

Peak  kbps 

8.20 

9.51 

12.56 

5.88 

9.04 

Average  bps_Rx 

738.00 

689.00 

1,521.00 

589.00 

884.25 

Average  bps_Sn 

187.00 

331.00 

625.00 

267.00 

352.50 

Total  KBytes_Rx 

2,878.00 

2,690.00 

5,818.00 

2,078.00 

3,366.00 

Total  KBytes_Sn 

731.00 

1,291.00 

2,393.00 

941.00 

1,339.00 



- 

' '■ 

‘ - - 

— 
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Key  messages  from  Collected  Data 


• The  average  bandwidth  to  user  is  between  0.5kbps 
(no  download)  to  1kbps  (with  download) 

• The  average  data  transferred  to  user,  in  one  day,  is 
between  2.2MB  (no  download)  to  3.7MB  (with 
download) 

• The  average  bandwidth  of  the  heaviest  user  for 
each  day  is  about  884  bps  (no  download)  to  2 kbps 
(with  download) 

NB:  These  numbers  include  all  traffic  (including  protocol  o/h)  to/ 
from  computer  and  hence  IP  traffic  will  be  a subset  of  this  data 


Sembi,  B.S.,  Armbruster,  B 


Estimates  from  Expert  Panel 


A process  was  designed  to  elicit  the  opinion  of  a number  of  ‘experts’  at  Vistar  for 
determining  the  user  traffic  characteristics 


estimates 


Initial  meeting  to 
obtain  consensus  on 
the  list  of  services  and 
the  process  involved 
Handout  of  existing 
knowledge  of  traffic 
characteristics 
Initial  discussion  of 
data  input 


- The  Experts  to 
provide  data  for 
consolidation  and 
analysis 


- Second  meeting 
to  review  the 
group  data  and 
achieve  consensus 
on  the  combined 
data 
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Services 


Remote  LAN 
Access 


Int.  Msging 
system 


Online 

Commerce 


Tele- 

medicine 


900 


300 


1000 


Distance 

Education 
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Ave  B/w 
to  User 
Kbps 

Mbytes  / 
Month 

9 

60.75 

48 

108 

64 

480 

64 

144 

1 6 

51 

32 

64.8 

64 

288 

341 .33 

2048 

85 

573.75 

Ave  B/w 
frm  User 
Kbps 


256  mins  1 


64  I mins 


Mbytes  / 
Month 

Peak  BAN 
frm  User 
Kbps 

6.75 

16.00 

2.25 

1 6 

120 

128 

2.25 

16 

6.375 

64 

2.025 

1 6 

576 

512 

6 

1 6 

64.8 

64 
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Results  from  Experts  Panel  ( Longer  Term ) 


Remote  LAN 
Access 


Int.  Msging 
system 


»„  Ave  B/w  / Peak  B/w 

Qos  to  . , Mbytes  / , 

..  frm  User  ' frm  User 
User  Month 


1500  256  2880  1544 


450  100  337.5  384  mins 


475  64  228 


360  50  135 


900  128  864 


128  mins  12 


512 


Tele- 

medicine 


Multimedia 

Download  on  1000  409.60  3072  2048  mins 

demand 


Distance 

Education 


1100  256  2112  1024 
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Summary  of  the  Bandwidth  Requirements 


Source 

BAV  to  User 

BAV  from 
User 

Data 

(MB/m) 

Comments 

ISP  Provising2  (All  net 
Applications) 

2.8  kbps 

18.9 

Provisioned  today  over 
large  number  of  business 
& Res.  users 

Guidelines  for  ISPs2  (All  net 
applications) 

5.76  kbps 

38.9 

Data  Telcos  would  like 
ISP  to  provision 

Lan  Measurements1 
(Browswer  Only) 

524  bps 

39.6 

Measured  for  Business 
users  today 

Literature  search3 (Browswer 
Only) 

8 kbps 

20  bps 

54 

Prediction  from  a recent 
model 

Experts  Panel  Near  Term 
(E.Browsing) 

9 kbps 

1 kbps 

60.7 

Near  term  predictions 
from  the  panel 

Experts  Panel  Longer  Term 
(E.B  rowsing) 

64  kbps 

9 kbps 

432 

Longer  term  (20 1 0) 
view  from  the  panel 

1 Average  during  business  hours.  Users  are  “active”  during  part  of  the  day.  Data  based  on  measured  values 

2 Actual/Proposed  provisioning(symmetric),  even  though  demand  is  asymmetric 

3 Does  not  include  protocol  overhead 
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Key  Findings 

• Internet  traffic  requirements  that  may  be  used  to  introduce 
service  in  the  near  term  are: 

- The  average  bandwidth  of  8kbps  per  user  is  reasonable 
bandwidth  to  introduce  service  over  the  near  term 

- Data  transferred  per  month  to  the  user  is  in  the  range 
between  25MB/month  for  residential  user  to  50MB/ 
month  for  business  user. 

• More  independent  results  are  required  to  get  statistically 
significant  values  and  to  take  into  account  wider  user 
patterns 

• Ongoing  tracking  is  required  to  better  understand  the 
evolving  traffic  characteristics  of  IMM  services 

Sembi,  B.S..  Armbrusler,  B VI  SI 
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Interoperability  for  Space  Mission  System 
Monitor  and  Control: 

Applying  Technologies  from  Manufacturing 
Automation  and  Process  Control  Industries 

Satellite  Networks  Workshop 
6/2/98 

Michael  K.  Jones 
818-354-3918 

michael.k.jones@jpl.nasa.gov 


Outline 

• Space  Project  Mission  Operations  Control  Architecture  (SuperMOCA) 
Goals  and  Methods  for  Achieving  Them 

• Some  Specifics  on  the  Architecure 

- Open  Standards  and  Layering 

- Enhancing  Interoperability 

- Promoting  Commercialization 

• An  Advertisement 

• Status  of  the  Task 

- Government  / Industry  Cooperation 

- Architecture  and  Technology  Demonstrations 

• Key  Features  of  Messaging  Services  and  Virtual  Devices 
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Space  Project  Mission  Operations 
Control  Architecture  (SuperMOCA): 
Goals  and  Methods 

Significantly  reduce  the  monitor  and  control  cost  for 
integration,  test,  operations  and  maintenance  of  ground- 
based  and  spaceborne  systems  used  in  space  missions 
Facilitate  space  industry  and  government  agencies 
cooperation  in  the  execution  of  space  missions 

Partner  with  industry  in  a consortium  environment  to 
develop 

- an  architecture  and  operations  concept  that  is  commonly 
understood  by  customers  and  suppliers 

- open  standards  based  on  technologies  and  open  standards  and 
from  manufacturing  automation  and  industrial  process  control 
industries 

- a lucrative  commercial  market  for  space  mission  monitor  and 
control  products 


Space  Mission  System  Monitor  & Control 


Payload  Operations 
Centery. 


“Virtuaf  Monitor  & 
Control  Path  for 
Payload  ^ 


“ Virtual*  Monitor  &■ 
Control  Path 
for  S/C  ^ ■ 


Payloac 


Spacecraft 

(S/C) 


“ Virtual*  Monitor  & * 
Control  Path  for  “ 


S/C  Operations 
Center 


Ground 

Terminal 


©Ops  or  Test  Center  \ Mission  System 

_Mon/for»ncf Control Dialogue 

T”  T t 


( System^ 
\of  Daviess 


Data  Communications 
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A definition  - Monitor  and  Control  (applications-level)  Interoperability: 
Once  connectivity  has  been  established  based  on  communications 
interoperability,  components  built  by  different  organizations  can  operate 
together  to  execute  an  activity  by  exchanging  monitor  and  control  information 
(i.e.,  plug  and  run) 

Advantages  for  space  mission  monitor  and  control 

- simplifies  multiple  agency  cooperative  missions 

- shortens  system  integration  and  test  and  training  time 

- preserves  customer  options  on  component  suppliers 
Advantages  for  commercial  products 

- lower  customer  support  costs 

- products  are  compatible  with  more  systems 
How  the  architecture  enhances  interoperability 

- makes  mission-specific  descriptive  information  available  to  monitor  and 
control  applications  in  a standard  structure  (Information  Architecture) 

- decouples  device  design  from  monitor  and  control  application  design 
(messaging  service  and  virtual  device  concepts) 


Promoting  Commercialization 

If  we  (the  customers)  want  to  benefit  soon  from  a commercial  market,  then  we 
need  to  participate  in  creating  it.  The  SuperMOCA  task  and  architecture  are 
intended  to  promote  a commercial  market.  Specifically  they  will: 


Provide  an  understanding  of  the 
common  cost  drivers'among 
government  and  commercial 
space  missions 

Reduce  costs  for  both  government 
and  commercial  operators 
throughout  the  project  life  cycle 
Provide  business  opportunities  to 
a large  set  of  companies 
Promote  commerical  competition 


I Academia.  Industi 

Candidate 
Technologies'1  f 


, Government! 

J Monitor  & Control 
T Needs  & Methods 


j Common  Framework 

-^1 

y for  Solutions 

w 

Suppliers 


Open  Standards  & 
Reference  Implementations 

I Projects  Using  ] 


Space 
Mission 
. Customers 


Path  to  a Commercial  Market 
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SuperMOCA  Homepage 


Status  of  Government  / Industry  Cooperation 

• FY  98  and  FY  99  funding  from  NASA’s  Space  Operations  Management 
Organization  (SOMO)  standards  program 

• FY  98  work  is  being  done  at  JPL  and  through  contracts  with  SRI  and  Fieldbus, 
Inc. 

• Will  get  support  from'Department  of  Defense  (DOD)  in  FY  99  to  incorporate 
any  DOD-specific  needs  into  the  architectural  design  work 

• Negotiated  a preliminary  Memorandum  of  Agreement  with  Fieldbus  Foundation 
(FF)  and  NASA  on  for  a cooperative  program  to: 

- demonstrate  FF  process  control  technology  being  developed  to  operate  in 
ethemet  networked  environments 

- develop  a space  monitor  and  control  industry  consortium  based  on  the  FF 
experience  as  a process  control  industry  consortium 

• Working  with  Fisher-Rosemount  (an  FF  member  company)  in  developing  a 
design  for  remote  access  to  monitor  and  control  systems  via  satellite  links 
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What  is  the  Fiefdbus  Foundation? 


Over  100  Companies 

Major  international  Automation  Companies 
Multi-national  End  Users 


Fieldbus  Foundation  Members 

• ABB  Industrial  Systems  Inc. 

- Fieldbus  International  A/S  (FINT) 

• Alfa  Laval  Automation  AB 

* Fisher  Controls  International,  Inc. 

• Allen-Bradley  Co.,  Inc. 

9 Flsher-Rosemount  Systems  Inc. 

• Allen-Bradley  Japan  Co.,  Ltd. 

» Fraunhofer  Institute  HTB 

• Alprat  (Pty)  Ltd. 

9 The  Foxboro  Company 

• Apparatebau  Hundsbach  GmbH 

9 Fuji  Electric  Co.,  Ltd. 

• Bailey  Controls  Company  • 

a Futon  Company,  Dekoron  Div. 

• Bailey  Japan  Co.,  Ltd. 

9 Glaxo  Inc. 

• Beamex  Oy,  AB 

9 GSC  Precision  Controls 

• Belden  Wire  & Cable 

9 Hartmann  & Braun  AG 

• Borst  Automation 

9 Hitachi,  Ltd. 

• Bray  International,  Inc. 

« Honeywell  Inc. 

- Bronkhorst  High-Tech  B.V. 

• ifak 

• Brooks  Instruments 

9 Institute  dm  invsstigaclons®  El&cfric m 

• Cal  ter  Services  Corporation 

9 Johnson  Yokogswa  Ccrp. 

• Chevron  Research  £ Technology 

9 K-Patante  Oy 

• di 

• DI 

• Druck  Ltd. 

■ du  Pont  Engineering  Co. 

•EMCO 

• Endress  + Hauser  GmbH 

• Enraf 

• Exxon  Research  & Engineering  Co. 


■ Knick  EJektronlsche  MeBgerttte  GmbH  &Co. 

■ Koso  Service  Co.,  Ltd. 

• KROHNE  Mesatechnlk  GmbH  & Co. 

■ Leeds+Northrup 

> Magnetrol  International 

• Maeonellan  - Dresser  Industries,  Inc. 
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Fieldbus  Foundation  Members 

• Measurement  Technology  Ltd. 

• Rosemount  Inc. 

• Mettler-Tolsdo,  Inc. 

• Saab  Tank  Control 

* Micro  Motion,  Inc. 

• Schneider  North  America 

• MILLTRONICS  Ltd. 

• Servomax  Company  Inc. 

• Mitsubishi  Electric  Corporation 

• Shell  Oil  Company 

• Monsanto  Company 

° Shimadzu  Corporation 

• Motoyama  Eng.  Works,  Ltd. 

* SHIP  STAR  Associates  Inc. 

• Nagano  Keiki  Saisakuaho  Ltd. 

• Slebe  ECD 

• National  Instruments  Corp. 

• Sieger  TPA  Ltd. 

• NEC  Corporation 

• Siemens  Industrial  Automation,  Inc. 

• Neles-Jamesbury  Oy 

• Simrad  Albatross  AS 

• NEMA 

• SMAR  Equipamentos  Industrials  Ltda. 

• Niigata  Masonelian  Co.,  Ltd. 

• Sotting  GmbH 

• Norsk  Hydro  a-s. 

• StoneL  Corporation 

• Ohkure  Electric  Co.,  Inc. 

• TMG  Mac  GmbH 

• Oval  Engineering  Co.,  Ltd. 

• Tokyo  Kelso  Co.,  Ltd. 

• Pacific  Avionics  Corporation 

• Toshiba  Corporation 

• Pepperi+Fuchs 

• Valmet  Automation  Inc. 

* POHTO 

• VALTEK  International 

• Poiitecnlco  dl  Torino  -Dai 

• VEGAGrieshaberKG 

• Presys  Instrumentos  e Sistemas  Ltda. 

• Vinson  Supply  Company 

• R.  Stahl  Schaltgerite  GmbH 

• WoridFIP  Europe 

- Ramsay  Technology,  Inc. 

• Yamatake-Honeywell  Co.,  Ltd. 

• Ronan  Engineering 

• Yokogawa  Electric  Corporation 

- Rosemount  Analytical,  Inc. 

• Yokogawa  Electronics  Co.,  Ltd. 

JPL 

Two-way  Tech  Transfer  Benefits  Both 
Process  Control  and  Space  Industries 


Space 


Industry 


s Expertise 


FFArchi 


Remote  Access  to 
Process  Control  Systems 
over  Satellite  Links 


Control 


Application 


Vendors 


Device 


Vendors 


vel  Control 


System 


Integrators 


End  Users 


Space  Devices  Space  Systems 

with  Commercial  with  Commercial 

Control  Control 

Architecture  Architecture 
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Demonstrations 

Overview  Documents  Available 

- Summary  - Why  SuperMOCA  is  important 

- Architecture  - What  SuperMOCA  is 

- Operations  Concept  - How  SuperMOCA  is  applied 

Current  Focus  is  on  messaging  services  and  virtual  devices 
Road  Show  Demo  ■ — mim.. 

- Commercial  messaging  system 

- ISA  Show  in  Anaheim  in  Oct.  97  %'  ■ ...  • 

■ FOUNDATION  I 

JPL  Demo  H*Wb“  | 

- Commercial  messaging  system 

- Simulated  S/C 


Ym*u  FRG-MOO  Rmhnr 


Lcwrance  GPS  Receiver 


Canon  VC-C1  Camara 
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Messaging  Services  and  Virtual  Devices 


Virtual  devices  consist  of  software-implemented  “objects”  that  represent  the 
extemally-visible  aspects  of  the  device 

Messaging  services  provide  the  capabilities  to  monitor  and  control  the  device 
through  manipulation  of  the  “objects” 

Fieldbus  Messaging  Service  (FMS)  is  an  example  of  an  integrated  architecture 
with  which  to  build  a monitor  and  control  system 

- set  of  messaging  services 

- set  of  virtual  device  “function  blocks” 


Externally  . 

^ . - Visible  I Device 

Messaging  Services  Software  I Drivers 
Operating  over  -objects- 

Data  Connection 
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Invited  Session 

NASA  Interoperability  Experiment 

Program 
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Page  intentionally  left  blank 


INTEROPERABILITY 

WHAT  IS  IT 
and 

WHY  IS  IT  SO  IMPORTANT  ? 


ALFRED  U.  MACRAE 

Consultant 
72  Sherbrook  Drive 
Berkeley  Heights,  NJ  07922 


INSTITUTE  FOR  APPLIED  SPACE  RESEARCH  - GWU 


INTEROPERABILITY  ENABLES 
COMMUNICATION  AND 
INTELLIGENT  INTERACTION  BETWEEN 
SYSTEMS  OF  DISSIMILAR  NETWORK 
ARCHITECTURES  AND  PROTOCOLS, 
USING  EQUIPMENT  MADE  BY 
DIFFERENT  VENDORS  AND  OWNED 
BY  DIFFERENT  SERVICE 
PROVIDERS. 


AUM  6/98 
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FACTORS  INFLUENCING 

INTEROPERABILITY 

Standards 

Compatible  Protocols 
Cost 

Reliability 

Customer  acceptance 
Technical  compatibility 
Inter-company  agreements 

AUM  6/98 

TRENDS  ON  THE  GROUND  (I 


Demand  for  bandwidth  is  increasing  at  50%  per  year 
Data  exceeds  voice  transport  in  U.S. 

Number  of  Internet  hosts  is  doubling  every  six  months 

Customers  are  obtaining  1 Mbps  to  home  with 
cable  modems 

T-1  lines  have  been  on  allocation 
Customers  are  ordering  DS-3  lines 

Customers  are  requesting  OC- 12  (622  Mbps) 

Transport  has  changed  from  multiples  of  DS-3  to 
multiples  of  OC-48  (and  higher)  AUM6/98 


200 


TRENDS  ON  THE  GROUND  fill 

Optical  technology 

DWDM  is  now  offered  at  80  channels  with  400  Gbps 
per  fiber,  increasing  to  1 Tbps  per  fiber,  with 
25  Tbps  possible 
Optical  add-drop 
Optical  cross-connect 

Sub-cabie 

Japan  to  U.S.  - by  mid  year  2000;  SONET  Ring, 

80  Gbps,  upgradeable  to  640  Gbps 
Project  Oxygen  - by  year  2002;  global,  74  countries, 
DWDM,  80  channels  per  fiber,  distance 
independent  charges 

(Bandwidth  is  plentiful,  but  access  to  the  home  is  key) 

AUM  6/98 


The  global  network  is  becoming  IP  based 
Convergence  of  data,  voice,  video 
The  network  has  gone  from  a hierarchical 
to  a distributed  architecture 
Real  Time  Network  Routing  (RTNR) 

SS  #7  (signaling)  is  the  basis  of  call  set-up, 
new  services,  and  network  management 
Network  management  is  complex  and  is 
the  key  to  customer  satisfaction 
Data  base  management  (as,  customer 
profile  information)  is  key  for  billing, 
new  services 

Wireless  mobile  is  booming,  esp  in  those 
parts  of  the  globe  that  use  standards  (GSM) 


AUM  6/98 
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TRENDS  IN  SATELLITES  (I 


Technical 

On  board  switching 
Multiple  spot  beam  antennas 
Larger  antennas 
Intersatellite  links 
Higher  power 

Multi-satellite  constellations  at  LEO  and 
MEO  to  minimize  delay  problem 
Software  is  becoming  increasingly  important 
Business 

Delivery  of  services  to  end-user*, 
as  DBS,  mobile  telephony,  Internet  access 
and  DARS  aum6/98 
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WHAT  ABOUT  DISTRIBUTION  of  HDTV? 


Distribution  of  TV  to  Network  Affiliates  and 
Cable  Head  Ends  is  Big  Business  Today 

Raw  high  definition  video  is  ~ 1 Gbps 

I 

Contribution  Quality  for  Editing  is  160  Mbps 

! 

Delivery  to  home  is  19.2  Mbps 


(FUTURE  SATELLITES  WILL  REQUIRE  HIGHER  I 

BANDWIDTH  TRANSPONDERS)  I 


AUM  6/98 


WHAT  ABOUT 


THE  1/2  sec.  LATENCY  AT  GEO? 


Voice 

Data 


Will  LEO  be  the  answer  for  satellites? 
But,  what  about  Doppler  (Jitter)? 
and  traffic  management? 


AUM  6/98 
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While  initial  studies  are  encouraging,  using 
Reed-Solomon  coding  and  the  COMSAT  Link 
Enhancer,  continued  studies  are  needed  to; 
determine  if  satellites  can  deliver  the  QOS 
demanded  of  present  and  future  ATM  services, 
to  understand  resource  management  and 
application  performance. 

(AT&T,  KDD,  Telstra  AKT  ATM  Technical  Trial) 


AUM  6/98 


PROTOCOLS  and  STANDARDS 


ATM 


Frame  Relay 


TCP/IP 


AUM  6/98 
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STANDARDS 


Enhance  Customer  Acceptance 

Mobile  telephony 


DBS 


DARS 

Common  air  interface  standards  will  be 
demnded  by  the  customers  and  will  be  good  for 
the  entire  business 


AUM  6/98 


TRENDS  IN  SATELLITES  (II 


INTEROPERABILITY 

Trunking  and  thin  route  services 

Will  require  higher  bandwidth  transponders  to 
carry  new  services 

Will  require  solution  to  the  latency  problem 
to  carry  high  bandwidth  TCP/IP  traffic 
Broadcast  TV 

Will  require  higher  bandwidth  transponders  to 
distribute  HDTV 

Will  require  lower  cost  (will  SONET  replace 

domestic  distribution?)  and  better  reliability 
Data  networks,  low  bandwidth 

Probably  ok  - being  done  now 


AUM  6/98 
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INTEROPERABILITY 

End-User  based  services  (all  need  improved  distribution  and 
service  channels) 

Internet  access  - Need  to  solve  latency  protocol 
problem  for  high  bandwidth  access,  need  to 
utilize  conventional  signaling  and  data  base 
management  to  match  services  provided 
by  terrestrial  counterparts 

DBS  - Need  standard  receivers  to  enhance  business, 
need  to  provide  local  programing 
Multicast  - New  protocols  needed 
Mobile  telephony  - Signaling,  routing,  standard 

terminals,  new  services  - location  determination 
DARS  - Quality  is  the  big  issue 


AUM  6/98 


Global  communications  are  increasing  at  an 
unprecidented  pace 
The  network  is  “going”  IP 
Data  transport  exceeds  voice 

Terrestrial  communications  is  “going”  high  bandwidth 

To  be  interoperable  with  the  terrestrial  network,  satellites 
need; 

higher  bandwidth  transponders,  OC-3? 
solution  to  the  latency  protocol  issues 
utilization  of  standard  signaling,  data  base  management 
and  network  management 
standardization  of  terminals 

AUM  6/98 
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Lewis  Research  Canter 


ONS,  & 
IOP 


June  3, 1998 
Cleveland,  OH 


“NEW  OPPORTUNITIES  WITH 
THE  ADVANCED  COMMUNICATIONS 
TECHNOLOGY  SATELLITE  (ACTS)” 
Robert  Bauer 
ACTS  Project  Manager 
NASA  Lewis  Research  Center 


Lewis  Research  Center 


ACTS  PROGRAM  OVERVIEW 


• Experiments  began 
December  6, 1993. 

• Initial  2 year  mission  life 
extended  to  4 years  (design 
life). 

• Fifth  year  now  underway. 

• Over  1 00  organizations 
involved  in  85  experiments; 
81  demonstrations  to  various 
audiences. 


Launched  September  12, 1993. 
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ACTS  SPACECRAFT  CHARACTERISTICS 

Lewis  Research  Center 


Weight:  3250  lbs  (on-orbit) 

Power:  1770  BOL 

Frequency  Band:  Ka  (30/20 
GHz) 

Space  Pointing  (Pitch  & Roll) 
Accuracy:  + 0.025 
Launch  Date:  September  12, 
1993 

Stationkeeping  Fuel  Expended: 
Projected  July,  1998 
Inclined  Orbit  Operations  (N/S 
not  maintained):  Through 
September,  2000 
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High  Gain,  Fast  Hopping  Spot  Beams 

• EIRP  >64  dB 

• G/T  >20  dB/K 

• Frequency  Reuse  > 4 


Onboard  Processing  & Switching 

• Baseband  Switching  at  64  kbps  circuit 
level 

• Max  throughput  of  220  Mbps 

• Full  mesh,  single  hop  connectivity 

• Wideband  Switch  Matrix  of  3 channels 
at  900  MHz  each 


Ka-Band 

• 30/20  GHz  RF  spacecraft  & 
earth  station  components 

• Propagation  measurements 
to  characterize  band 

• Adaptive  rain  fade 
compensation 

• Only  currently  available 
30/20  GHz  satellite  testbed  in 
U.S. 


Lewis  Research  Center 


ACTS  ACCOMPLISHMENTS  (selected) 


• Inducted  into  Space  Technology  Hall  of 
Fame,  April  1997. 

• Highest  known  data  rates  supported  in  a 
single  transponder  by  a non-DoD  satellite 
(622  Mbps). 

• Experiments  have  been  supported  in  31 
states  and  6 foreign  countries. 

- Using  multiple  satellites,  have  linked  to  Europe 
and  Asia. 

• Experiments  and  demonstrations: 

- from  planes,  trains,  automobiles,  and  ships 

- from  volcanoes,  deserts,  rain  forests,  islands, 
and  battlefields 

- with  scientists  & engineers,  patients  & doctors, 
politicians  & soldiers,  educators  & students... 
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INCLINED  ORBIT  OPPORTUNITY 


WHY  EXTEND  THE  PROGRAM?? 

✓ Successful  experiments  program. 

■/  Sustained  interest  and  impressive  results  have  driven  the 
desire  to  continue  ACTS  as  long  as  reasonable/possible. 

✓ Minimal  further  cost  to  achieve  maximum  benefit  from 
investment  to  NASA  and  Nation. 

✓ Program  constraints  define  end  of  life  at  September,  2000. 

✓ Test  viability  of  narrow  spot  beam  system  in  10. 

✓ No  failure  of  primary  systems. 

✓ Efficient  stationkeeping 

✓ Calculations  show  sufficient  fuel  to  operate  for  30  mos.  in 
inclined  orbit. 

✓ Maintain  spacecraft  at  100°  + 0.05°  West  longitude. 
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Lewis  Research  Center 


Prepare  the  system  for  supporting  inclined  orbit 
operations. 

- Implement  new  spacecraft  procedures  to  maintain  attitude. 

- Install  and  test  modified  ground  segment. 

Continue  operations  with  a tracking  ground  segment 
to  support  program  plans  and  experiment  operations 
requirements  through  September  2000. 

Minimize  impact  to  experiment  operations 


INCLINED  ORBIT  IMPACT 


Spacecraft 

• Satellite  will  drift  in  N/S 
direction  increasing  by  ~0.8° 
per  year 

• ACTS  East/West  maintained 
at + 0.05°  for  up  to  27 
months. 

• Last  North/South  maneuver 
planned  for  July,  1998. 

• About  1 month  for  S/C  to 
exceed  0.05° 

Ground  Segment 

• Tracking  modifications 
underway  (2  axis) 


ACTS  Drift  Inclination 
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Lewis  Research  Center 


1 . Demonstrate  transitioning  to  future  commercial  satellite 
services  in  support  of  NASA  & other  government 
missions. 

2.  Test,  verify  & resolve  technical  issues  using 
Asynchronous  Transfer  Mode  (ATM),  Internet  Protocol 
(IP),  or  other  protocols  over  satellite,  including 
interoperability  issues  with  terrestrial  networks. 

3.  Characterization  of  the  ACTS  system  and  operations  in 
inclined  orbit. 

4.  Verify  new  satellite  Ka-band  technology  and  hardware. 


Lewis  Research  Center 


RECENT  ACTIVITY 


“Testing  New  Modalities  of  Space  Communications” 

- Major  aerospace  firm  and  team  of  several  networking 
hardware  and  software  providers. 

- Demonstrate  network  and  protocols  that  could  lead  to 
consolidation  of  NASA  space  operations. 

FTP,  TCP/IP,  HTTP  testing  over  ACTS 

- Ohio  University  and  LeRC  collaboration 
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#11 8x  (“High  Speed  Protocol  Optimazation”) 

• Dispell  myth  that  GEO  satellites  and  TCP/IP  are 
incompatible. 

- Investigate  protocol  performance  on  a multi-platform,  geosync 
satellite  network 

- OC-3  & OC-12  rates;  symmetric  & asymmetric  links 

- Optimize  point-to-point  transfer  of  data  between  two  sites  across 
ACTS  (HDR’s  at  LLNL  and  LeRC) 

- Use  TCP/IP  over  Asynchronous  Transfer  Mode  (ATM)  among 
multiple  computer  platforms  and  operating  systems. 

- Wide  variety  of  partners  including  top  names  in  industry: 

• Computer  Industry  - 7 orgs. 

• Communications  Industry  - 4 orgs 

• Satellite  Industry  - 6 orgs 

• Government  Laboratories  - 4 orgs 


Lewis  Research  Center 


EXPERIMENT  PROCESS 


• Submit  Letter  of  Intent,  or  better  yet. . . 

• Submit  experiment  proposal. 

• Review  for  feasibility  (S/C,  ground  segment,  schedule), 
meets  goals. 

• Space  Act  or  other  appropriate  agreement  developed 
with  all  experimenters. 

- ensures  requirements  defined 

- most  agreements  are  reimbursable 

- benefits  Experimenter  as  well  as  NASA  by  clarifying  what’s 
expected  of  both  parties. 
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Lewis  Research  Center 


ACTS  EXPERIMENTS  POINT  OF  CONTACT 


• ACTS  Project 

NASA  Lewis  Research  Center 
21000  Brookpark  Road,  MS  54-6 
Cleveland,  OH  44135 

ATTN:  Michael  Zemic,  ACTS  Experiments  Manager 

PH:  216.433.5286 
michael.zernic@lerc.nasa.gov 

• ACTS  Home  page 
http://acts.lerc.nasa.gov 
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Satellite  Networks  Workshop 
Cleveland,  Ohio 
June  3,  1998 


R.desJardins 

NASA  NREN/NGI  Project  Office 
rdesjardins@arc.nasa.gov 


/ Advanced 
( Networking 
i Science  & 

\ Technology 


DARPA 

($40  M) 

Basic  technology 
research; 


NSF 

($23  Ml 
Connectivity  & 
technology  delivery  to 
^search  universities; 
net2: 


Advanced  Networking: 
NASA’s  Relationships 
with  Other  Agencies 


NASA 

($10  M) 

Applied  research 
for  end-to-end 
systems 

BBterbament  and 


NIST 

($5  M) 
Standards 
development; 


NIH 

(SS  M) 

Advanced  medical 
application  demos; 
medical  research; 

healthcare 
. applications 


tij^Mvan  ced  \ 
jKtworking  \ 
f services  j 
.delivered to  / 
*K.users„S 


NGI/12  Comparison 


Next  Generation 
pren2  Internet  Architecture  jj 


Next  Generation  Internet 

Federal  funding 

Agency  mission  driven 

R&D  in  advanced  networking  technologies, 

and  demonstrations  on  a wide-area  scalable 

testbed  which  connects  to  academic 

(including  some  Internet  2 universities)  and 

industry  networks 

Develop  general-purpose  and  agency- 
specific  applications 


Internet 

Funded  by  research  universities  and 
communications  and  computing  companies 
Education  and  research  driven 
State-of-the-practice  connectivity  deployed  at 
universities  and  GigaPOPs  and  interconnected 
using  NSF's  vBNS  as  the  backbone 
Deploy  networking  technologies  and  develop  a 
wide  range  of  applications  (many  funded  by 
Federal  initiatives  such  as  NGI) 


Mid  Atlantic  GigaPOP  for  Interne 


[ KASAI 
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Capability 


— 


1 


Today 

• ‘Best  Effort- 

• Unicast  (point-to-point 
networking) 

• Lots  of  human 
intervention  required  to 
manage 

• Security  handled  by  host 

• Router-to-router 
performance  monitoring 


Tomorrow 

• Differentiated  services 

• Intelligent  network  (scalability) 

• End-to-end  performance 
management  policies  and  tools 

• Security  as  part  of  the  network 

• End-to-end  performance 
measurement 

• Qualities  of  service 

• Multicast 

• End-to-end  service  guarantees 


Capacity 


Today 


• Internet  exchange  points 
are  bottlenecks 

• Newer  applications  don't 
have  enough  bandwidth 

• Available  bandwidth  is 
poorly  utilized 

• Duplicate  traffic  slows 
growth  of  advanced 
applications 


Tomorrow 

• Robust  internetworking 
exchanges  move  the  traffic 

• New  technologies  provide  wide- 
open  bandwidth 

• Networks  are  unclogged  by 
high-speed  applications  running 
over  high-speed  networks 

• Multicast  reduces  traffic 
exponentially 
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Today 

Tomorrow 

• Electronic  mail 

• Collaboratories 

• File  transfer 

« Metacomputing 

. World  Wide  Web 

• Distance  learning 

• Remote  login 

• Telemedicine 

• Travel  to  meetings 

• Integrated  design  systems 

• Isolated  design 

• Remote  operation  j 

systems 

NASA  Mission  Application  Partners 


Astrophysics 


Accelerate  network 
technology  development  to 
meet  NASA  unique  mission 
requirements  today. 


Earth  Sciences: 
Advanced  Earth  Sciences 
Investigations 


Astrobiology  Institute 
Collaboratorles,  Virtual 
Aerospace  Environment 


Space  Exploration 


Telemedicine,  interactive 
. Consultations,  Remote 
Protocols  and  Procedures 


Advanced  Aerospace  Design  Information 
Power  Grid,  Wind  Tunnels  on-line,  Virtual 
Flight  Simulation  Laboratories 
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NASA  RESEARCH  AND  EDUCATION  NETWORK 


SIRIN 


NASA/NREN 

Next  Generation  Internet  (NGI)  Activities 


Richard  desJardins 
Ken  Freeman 


Tomorrow's  Networking  Applications  Today 


NASA  RESEARCH  AND  EDUCATION  NETWORK 

Agenda 

m 

• NREN  /NGI  Architecture 

• NREN  Applications 

• NREN  Applied  Research 

Tomorrow's  Networking  Applications  Today 
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NGI  Architecture 


NASA  Research  and  Education  Network  (NREN) 

NASA  Funded 
ATM  Backbone 

Very  High-Speed  Backbone  Network  (vBNS) 

NSF  Funded 
ATM  Backbone 

Earth  Sciences  Network  (ESnet) 

Department  of  Energy  Research  & Operational  Network 
ATM  Backbone 

Defense  Research  and  Education  Network  (DREN) 

ATM  Backbone 

SuperNet  (Terabit  Research  Network) 

DARPA  Funded 

Basic  Research  (ATM,  SONET  & WDM) 

Abilene 

Internet  2 Backbone 
Packet  over  SONET 


Tomorrow's  Networking  Applications  Today 


NREN 


ESfet 


.vE3N£ 


| NGIX-Wast 

Meffett  Flet<t  CA 


SuiSgteet 


NevYork,  NY 
-GSFC 
Gro*nO*t,  MO 
NGIX-East 
WaaHnotcn,  D.C. 


DREN-  PshBWHMWwIi  tEngw—rtng  Mtwortc 
NR&4-  NASA  RMMnhand  EduoMlon  NmicA 
ESrwK  - En«^y  N*tooifc  (DOE) 

wBUS  - Vary  High  Sp«*d  Backborw  Network  S«r<to*  (NSF) 
NOTE:  vfiNS  w ■ support  tnWoJ  Mamet  2oommunfcy 
Cupirfkt  - TareWt  Rosoeroh  Nwodt  (DARPA) 
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NGI  Architecture 


Ames-NGI  Exchange  Point  (NGIX-West) 


NASA  RESEARCH  AND  EDUCATION  NETWORK 


NREN  Architecture 

• ATM  Based  Backbone 

• Sprint  ATM  Service 

• OC-3  & DS-3  Circuits 

• ATM  & IP  Routed  Based  Connections 

• Interconnections  to  NGIX's 

• Connections  to  Five  NASA  Research  Centers 

• Planned  Connections  to  Operational  Centers 

• Connections  to  Boeing 

• Seattle 

• Long  Beach  (MacDonnel  Douglas) 

Tomorrow's  Networking  Applications  Today 
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NASA  RESEARCH  AND  EDUCATION  NETWORK 


LullDjVJ  iM  i^Tij  [M  iWirTri 


NASA  missions. 

Focus  is  on  end-to-end  application  demonstrations  in 
realistic  network  environments,  pushing  limits  of 
scalability. 

Integrate  emerging  technologies  into  NASA/NGI 
Applications. 


Tomorrow’s  Networking  Applications  Today 


NASA  RESEARCH  AND  EDUCATION  NETWORK 


NREN  Applications 


Accelerate  network 
technology  delivery  to 
meet  unique  NASA 
unique  mission 
requirements  today. 


Virtual  Flight  Simulation  Laboratories 


Telemedicine,  Interactive 
Consultations,  Remote 


Tomorrow’s  Networking  Applications  Today 
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NASA  RESEARCH  AND  EDUCATION  NETWORK 


integration  of  Kerberos  and  PKI 

Multicast:  Pilot  and  deployment  of  a large  scale  native 
multicast  network 

IPv6:  Introduce  IPv6  as  an  enabling  technology  for  scaling  QoS, 
multicast  and  other  new  services 

Routing-with-Switching:  Experiments  in  high  performance 
core  network  switching  and  routing  elements 


'Tomorrow's  Networking  Applications  Today  j 
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NASA  RESEARCH  AND  EDUCATION  NETWORK 


NREN  Applied  Research  NREN 

Congestion  Control:  Deploy  ATM  based  ABR  and  CBR 
services.  Weighted  Random  Early  Drop  (WRED) 

Giga/Terabit  Technologies:  Deployment  of  gigabit  and  terabit 
networking  strategies 

Network  Management:  Investigate  self  healing  networking 
strategies 

Performance  Benchmarks:  Develop  an  Internet  standard  suite 
of  performance  benchmarks 

NGI  Exchanges:  Interconnect  with  other  NGI  networks  and 
with  foreign  research  networks  at  NGI  exchanges  (NGIXs) 

GigaPoPs:  Connect  to  selected  gigapops  for  NASA 

applications  requiring  high  performance  connections  to 
university  sites. 
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GMr&^axWhole  is  womwide  hetw^  mpaetworks  wfoqj 
crWnea  global  infommuon  marketplace,  encouraging  b 
based  social  discourse  within  and  among  all  countries. 


GII 

Benefits  to  the  U.S.  Econom 


Direct  and  Indirect  Employment  Benefits 
Exports  (PositiVe  Trade  Balance) 
Technological  Leadership 


$ 
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1 . Global  Inventory 

2.  Global  Interoperability  of  Broadband  Networks  (GIBN) 

3.  Cross-Cultural  Education  and  Training 

4.  Electronic  Libraries 

5.  Electronic  Museums  and  Galleries 

6.  Environment  and  Natural  Resources  Management 

7.  Global  Emergency  Management 

8.  Global  Healthcare  Applications 

9.  Government  On-line 

10.  Global  Marketplace  for  Small  and  Medium  Enterprises 

11.  Maritime  Information  Systems 


Global  Interoperability  for  Broadband 
Networks  (GIBN)  Mission 

US  Perspective: 

• Establish  strong  Government,  industry  and 
academia  partnerships. 

• Formulate  clear  objectives  for  experimentation. 

• Emphasis  that  US  Industry  is  an  important  partner. 

• Foster  International  cooperation  with  non-US 
government  agencies,  universities  and  industry 
partners 
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ity  for  Broadband 
Networks  (GIBN):  ^Principles" 


To  establish  experimental  intercontinental  communications  links 
among  the  three  main  geographic  areas  of  the  G-8  countries:  North 
America,  Europe  and  Japan. 

To  provide  a common  testbed  for  the  promotion  of  joint 
Satcom/Terrestrial  Interoperable  R&D,  demonstrations  and  pre- 
commercial trials  of  advanced  high  data  rate  (>45  MBPS)  services 
and  applications. 

To  encourage  research  initiatives  promoting  science,  education  and 
commerce,  as  well  as,  social  and  cultural  development. 

To  develop  advanced  interoperable  communications  & information 
systems  and  networks  that  support  emerging  G8  information  society 
applications 

The  GIBN  will  be  the  interoperable  testbed  for  the  other  10 
information  society  projects. 


Global  Interoperability  for  Broadband 
Networks!  ^Objectives  and  Goals" 


To  promote  the  role  of  satellites  in  the  Global 
Information  Infrastructure  (Gil). 

To  analyze  the  barriers  of  seamless  interoperability 
between  satellite  and  terrestrial  communications 
systems;  promote  networks  and  system  modifications 
to  software  or  hardware  to  overcome  such  barriers. 

To  integrate  US  industry  products  and  services  as  an 
essential  part  of  applications/demonstrations. 

Recommend  changes  in  standards,  where 
appropriate,  to  overcome  barriers  of  interoperability 
between  satellites  and  terrestrial  systems. 

Extend  connectivity  of  networks  to  non  G-8  countries 
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Networks:  Background' 


The  White  House  National  Economic  Council,  invited  NASA  to 
formally  participate  in  planning  and  co-coordinate  jointly  with 
NSF  the  U.S.  contribution  to  the  G7  GIBN  project. 

* “...the  series  of  Trans-Pacific  experiments,  and  others  planned  for  the  Atlantic 

and  Asia-Europe  regions,  will  make  a very  significant  contribution  to  the  G-7 
Global  interoperability  for  Broadband  Networks  project” 

NASA  tasked  to  undertake  planning  to  support  and  promote 
additional  Trans-Pacific  and  Trans-Atlantic  GIBN  experiments 
which  provide  satellite  connectivity  to  NREN  and  STAR  TAP. 
Applications,  such  as,  digital  libraries,  telemedicine,  tele- 
education,  and  electronic  commerce;  that  contribute  to  NGI 
design  and  implementation  were  considered  solid  candidates 
for  future  GIBN  contributions. 

* Thomas  A.  Kaiil,  Senior  Director,  National  Economic  Council,  The  White  House 


Global  Interoperability  for  Broadband 
Networks:  /7NASA  Status" 


NASA  LeRC  Space  Communications  Program  assigned  to  lead  GIBN 
projects.  Participation  by  JPL,  GSFC,  and  ARC. 

Successfully  completed  the  first  Trans-pacific  satellite  post-production 
video  experiment  and  demonstration  (March  /April  1997,  JPL  - CRL) 
Assessment  of  the  “Science,  Technology  and  Research-Transit  Access 
Point”  (STAR  TAP)  site  (at  Univ.  of  III.— Chicago)  for  installation  of 
satellite  ground  terminal. 

LeRC  will  host  Intelsat  compatible  Ku-band  satellite  terminal;  scheduled 
for  completion  in  September  1998. 

Three  GIBN  project  applications  cunently  in  works;  they  are:  Radio- 
Astronomy  (Trans-Pacific)  [JPL];  Digital  Libraries  (Trans-Pacific) 
[GSFC];  and  Operation  Smile  (Trans-Atlantic)  [GWU]. 

European  Commission  (EC)  interested  to  establish  connectivity  with  US 
via  satellite.  Several  other  candidate  for  Trans-Atlantic  experiment 
under  review. 
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Global  Interoperability  for  Broadband 
Networks:  ^Experiment  Selection  Criteria' 


• Information  exchange  with  Trans-Atlantic  or  Pacific 
partners;  not  just  NASA’s  demonstration. 

• Opportunity  for  U.S.  Industry  to  contribute  hardware, 
software,  intellectual  resources  and  learn  about 
interoperability  issues. 

• Develop  and  demonstrate  state-of-the-art,  unique 
communications  systems,  networks  and  applications. 

• Foster  ground-breaking  use  of  communications 
activities  in  particular  wireless. 

• Encourage/seek-out  NASA  mission  tie-in. 

• Promote  connectivity  to  non  G-8  countries  via  Satellite 
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nteroperability  for  Broadband 
Networks:  ^Satellite  Industry  Involvement" 


> SITF  Requirements  are: 

» Seamless  interoperability  between  terrestrial  and 
satellite  networks  which  is  a major  problem  in 
providing  emerging  broadband  services  to  the 
end  users 

» In-Space  Technology  demonstrations  are 
required  for  timely  utilization  of  advance 
technologies  in  future  communications  satellite 
systems  and  applications. 

o In  systems... A series  of  interoperability  demonstrations 
are  needed  to  achieve  integration  of  satellite  and 
terrestrial  networks. 


Global  Interoperability  for  Broadband 
Networks:  ^Current  Experiments" 


Trans-Pacific  Radio-Astronomy  [JPL,  CRL/MPT] 

• Justification: 

» Science  and  Education:  Interactive  image  transmission 
from  telescopes  in  the  U.S.  and  Japan. 

» builds  on  the  successful  Trans-Pacific  HDTV  demonstration: 

» potential  to  demonstrate  OC-3  [155Mbps]  data  rates  over 
commercial  satellite. 

• Schedule: 

» Demonstration  planned  for  4th  Quarter  FY98; 

» Virtual  Internet  Testbed  simulations  and  Final  Report,  1st  & 2nd 
Quarters  FY99 
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Networks  Current  Experiments[continued] 


Operation  Smile-Telemedicine  [GWU] 

» Justification: 

- Trans-Atlantic  experiment; 

- Global  Multicast  Internet  Distribution 

- High  level  of  G-8  telemedicine  involvement;  positive  exposure. 

» Schedule: 

» 3rd  or  4th  Quarter  FY98 

Trans-Pacific  Digital  Library  Experiment  [GSFC/JPL] 

» Justification: 

- builds  on  the  successful  Trans-Pacific  HDTV  demonstration; 

- demonstrates  one  of  the  G-7  project  theme  of  Electronic  Libraries; 

» Schedule  (tentative): 


Global  Interoperability  for  Broadband 
Networks!  ^Current  Experiments" [continued] 


Trans-Atlantic  GIBN  Experiment  over  PanAmSat: 

» Networking  Trade.Show,  22-25  June  1998,  at  Birmingham,  England 

» ATM  Forum  sponsoring  booth  to  present  ATM  related  technologies 

» Offered  to  highlight  NASA  ATM  over  Satellite  and  ATM  Forum  work 

» ATM  over  Satellite  Technologies  / Quality  of  Service  Video  presentation 
MPEG2 

» During  LeRC  Conference,  several  short  (5  mins)  lectures  by  Industry 
leaders  will  be  recorded;  then  presented  at  the  trade  show  via  the 
broadband  network. 

» Voice  over  IP  over  ATM 

» PanAmSat,  MetroData  and  NASA  have  partnered  to  present  ATM 
Technologies  Demonstrations  over  PanAmSat  link. 
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Challenge  for  GIBN  Project 


• We  must  view  each  other  as  potential  partners 
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Plenary  Session 

Addressing  Interoperability 
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Addressing  Interoperability 
Issues  and  Challenges 


Raj  Jain 

The  Ohio  State  University 
Columbus,  OH  43210 
Jain@CIS  .Ohio-State.Edu 


□ Life  Cycle  of  Technologies 

□ Interoperability  and  Standards  Issues 

□ ATM  Traffic  Management 


The  Ohio  State  University  Raj  Jain 
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Life  Cycles  of 
Technologies 


Number  of 

Problems 

Solved 


Phase  1 Phase  2 Phase  3 

□ Phase  1 : Research 

□ Phase  2:  Productization 

□ Phase  3:  Transition  to  the  next  technology 

The  Ohio  State  Universi 
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Life  Cycle: 
Satellite  Networking 


Number  of 

Problems 

Solved 


Satellite 

Networking 

1 

1998 


Time 


□ Phase  1 : Research  Proprietary/competing  solutions 

□ Phase  2:  Standard  based  interoperable  solutions 


The  Ohio  State  Univerei 
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Networking: 
Failures  vs  Successes 

□ 1980:  Broadband  Ethernet  (vs  baseband) 

□ 1984:  ISDN  (vs  Modems) 

□ 1986:  MAP/TOP  (vs  Ethernet) 

□ 1988:  OSI  (vs  TCP/IP) 

□ 1991:  DQDB 

□ 1992:  XTP  (vs  TCP) 

□ 1994:  CMIP  (vs  SNMP) 


The  Ohio  State  Universi 


Rai  Jain 
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Requirements  for  Success 


□ Low  Cost 

□ High  Performance 

□ Killer  Applications  ^ 

(Remote  areas,  Distance  Insensitive, 
Multicast) 

□ Timely  completion 

□ Manageability 

□ Interoperability 

□ Coexistence  with  legacy 
(terrestrial)  networks 

The  Ohio  State  Universi 
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Interoperability: 

Example 

^Ameritech^)- 
□ Phone  System:  Any  phone,  any  carrier(s),  any  place 


The  Ohio  State  Universi 
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Interoperability? 

C Hughes  j 
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□ Satellite  Network:  Any  dish,  any  satellite  system,  any 
place 


The  Ohio  State  Universi 


Layers  of  Interoperability 


Network 


Datalink 


Network 


Datalink 


□ Physical:  Spectrum  Management, 
Common  Air  Interface 

□ Datalink:  DAMA/MAC 

□ Network:  Mobility,  Handoff 

□ Transport:  Satellite/Terrestrial  TCP/ATM 

□ Application:  Paging,  Data,  Messaging 

The  Ohio  State  Univereitv 
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Standards:  A Partial  List 

□ Telecommunication  Industries  Association  (TIA) 
o Common  Air  Interface 

o Spectrum  Management 

□ International  Telecommunications  Union  (ITU) 
o QoS 

□ ATM  Forum 

o Wireless  ATM 
o Traffic  Management 


The  Ohio  State  Univeisi 


Why  ATM? 

□ ATM  vs  IP:  Key  Distinctions 

1 . Traffic  Management:  Explicit  Rate  vs  Loss  based 

2.  QoS  based'routing:  PNNI 

3.  Signaling:  Coming  to  IP  in  the  form  of  RSVP 

4.  Switching:  Coming  to  IP  as  label  switching 


The  Ohio  State  Universi 
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Our  Goal 

□ Ensure  satellite/terrestrial  interoperability  in  ATM  TM 

o Ensure  that  the  new  ATM  Forum 
TM  4.0/5.0  specs  are  “Satellite-friendly” 

o There  are  no  parameters  or  requirement  that  will 
perform  badly  in  a long-delay  satellite  environment 

o Users  can  use  paths  going  through  satellite  links 
without  requiring  special  equipment 

o Develop  optimal  solutions  for  satellite  networks 


This  work  is  sponsored  by 
NASA  Lewis  Research  Center 


The  Ohio  State  Univerei 


Issues 

□ Binary  vs  Explicit  Rate  Feedback 

□ ABR  vs  UBR:  Available  bit  rate  vs  Unspecified  bit  rate 

□ Improving  performance  over  ABR:  VS  AD 

□ Improving  Performance  over  UBR:  Guaranteed  Rate 

Note:  The  alternative  that  is  best  for  satellite  networks 
may  or  may  not  be  so  for  terrestrial  networks. 


Satellite 


Terrestrial 


The  Ohio  State  Universi 
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Current  Cell  Rate 


□ Binary:  Explicit  forward  congestion  indication  (EFCI) 
bit  in  the  cell  header  set  by  congested  switches. 

Based  on  DECbit  scheme. 

□ Explicit  Rate:  Sources  send  one  RM  cell  every  n cells. 
The  switches  adjust  the  explicit  rate  field  down. 

The  Ohio  State  University  Raj  Jaill 


Binary  vs  Explicit 
Feedback 
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Why  Explicit  Rate 
Indication? 

□ Longer-distance  networks 

=>  Can’t  afford  too  many  round-trips 
=>  More  information  is  better 

□ Rate-based  control 

=>  Queue  length  = ARate  x ATime 
=>  Time  is  more  critical  than  with  windows 


The  Ohio  State  Universi 


VS/VD 

□ Without  Virtual  Source/Virtual  Destination: 


□ With  VS/VD: 


Bottleneck 


Satellite  Workgroup 

Link  Switch  . 

□ With  VSVD,  the  buffering  is  proportional  to  the 
delay-bandwidth  of  the  previous  loop 
=>  Good  for  satellite  networks 


The  Ohio  State  Universi 
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□ Intelligent  transport  or  not? 


The  Ohio  State  Univerci 
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ABR  vs  UBR 


I Source! 


Sourcer  Router 


I Dest. 


Dest. 


ABR 

UBR 

Queue  in  the  source 

Queue  in  the  network 

Network  Qs  = k RTT 

Network  Qs  = S Windows 

Pushes  congestion  to  edges 

No  backpressure 

Good  iff  end-to-end  ABR 

Good  iff  TCP. 

Fair 

Generally  unfair 

The  Ohio  State  University 

Rai  Jain 
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Ways  to  Improve 
UBR  over  Satellites 

1.  Reserve  a small  fraction  of  bandwidth  for  UBR  class 
in  the  switches  =>  Guaranteed  Rate  Service. 

o For  WANs,  the  effect  of  reserving  10% 
bandwidth  for  UBR  is  more  than  that  obtained  by 
EPD,  SD,  or  FBA 

o For  LANs,  guaranteed  rate  is  not  so  helpful.  Drop 
policies  are  more  important. 

2.  Implement  “Selective  Acknowledgement”  in  end- 
systems.  Disable  “Fast  retransmit  and  recovery”  in 
end-systems. 


The  Ohio  State  Univerai 
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Summary 


□ Interoperability  is  the  key  to  success  of  a technology 

□ Layers  of  interoperability:  Air  interface  to 
applications 

□ ER  better  for  satellites  than  Binary  feedback. 

□ ABR  better  than  UBR  for  long-delay  paths 

□ VS  A/D  can  help  reduce  the  impact  of  satellite  delays 

□ Reserving  a small  capacity  helps  UBR 


The  Ohio  State  Universf 
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Ill 


□ Guaranteed  Rate  (GR):  Reserve  a small 
fraction  of  bandwidth  for  UBR  class. 


iGR 


er-class  reservation 


er-class  schedulin 


IGFR 


er-VC  reservation 


er-VC  accounting/schedulin 
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Future 
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When  will  satellite  technology  really  take  off? 
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Our  Publications 

All  our  ATM  Forum  contributions  and 
papers  are  available  on-line  at 
http://www.  cis.  ohio-state.  edu/~iain/ 

□ Specially  see  “Recent  Hot  Papers” 


The  Ohio  State  Univemt 


Raj  Jain 
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Transitioning  NASA 

Space  Operations  to  Commercial 
Services 


NASA/LeRC  Satellite  Networks  Workshop 


June  2-4, 1998 


Charlene  E.  Gilbert 
Space  Operations  Management  Office 
Technology  Program  Manager 
NASA  Johnson  Space  Center 

chariene.s.gilbert1@jtc.nua.gov 


Space  Operations  Management  Office 
National  Aeronautics  and  Space  Administration 


Major  Considerations  in  Transitioning  NASA  to 
Commercial  Services 

• Government  use  of  commercial  frequencies  vs  commercial  use  of 
commercial  frequencies  for  Government  use 

• Commercial  use  of  Government  frequencies 

• Government  vs  commercial 

- Access  techniques 

- Data  formats 

- Modulation  & coding 

• Government  need  for  multiple  sources 

- Backup 

- Competition 

• Government  in  perceived  competition  with  commercial  service 
providers  if  TDRSS  is  used  for  commercial  purposes 

• Coordination  required  among  plans  for  CSOC,  NSCP,  and  Satellite 
Industry 

SOMO  Commercial  Alternatives  Study 
LeRC 
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* * 

Interoperability  Issues 

IRIDIUM 

Fundamental  Issues 

• Development  of  common  interfaces 

- Eliminate  proprietary  systems 

- International  acceptance  and  development 

- Incorporates  advanced  features 

- Meets  growing  data  networks 

-ATM 
- TCP 

• Evaluate  network  as  a hybrid 

• Flexibility  and  growth 

June  22,  1998 

Interoperability  Issues 
Example 

• Integration  of  wireless  network 

- System  designed  as  a single  solution  domestic 

- Four  network  types  converging  to  two 

- DMX 

- GSM  - GSM 

- IS-41  - IS-41 

- PDC 

- Satellite  integration  has  raised  issues 

• Interoperability  of  data  networks 

- ATM  implementation 

- Frame  relay  implementation 


June  22, 1998 
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Interoperability  Issues  IRIDU 

Resolution  and  lessons  learned 

• Integrate  networks  at  the  lower  levels  and  incorporate  mediation 
devices 

- Special  development  is  required 

- Performance  and  functionality  is  decreased 

- Network  flexibility  is  reduced 

• Develop  defined  specifications  that  support  seamless  use 

- International  participation  is  required 

- Backwards  compatibility  is  required 

- Market  drives  applications  and  usage 


Interoperability  Recommendations 
Focus  areas 

• Standards  committees 

- U.S.  entities  need  to  be  proactive 

- International  development  is  important 

- Design  for  hybrid  networks  and  flexibility 

• Strategic  planning  of  technical  effort  is  crucial 

- Enhancement  of  “basic”  areas 

- Hardware 

- Network  Intelligence 

- Industry  involvement  and  coalescence 

• Address  all  markets  -(DoD  and  Private) 


June  22, 1998 
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IRIDIUM 


Satellite  Networks  Workshop  ‘98 
Iridium  Services 
Mark  Plecity 

June  22, 1998 


Flexible  Service  Offering  ,RID'1 

Based  on  his  communications  needs,  the  customer  chooses: 

• A home  network 

- Satellite  Network 

- Wireless  Network 

• The  appropriate  subscriber  equipment 

- Satellite  subscriber  equipment 

- Wireless  telephone 

- Pager 

These  choices  then  determine  which  components  of  the 
IRIDIUM  Service  the  customer  has  access  to. 
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Interoperability 

Sastri  Kota 
Technical  Consultant 
Interactive  Technology  Center 
Lockheed  Martin  Telecommunications 
408-543-3140 
sastri.kota@imco.com 

NASA  Lewis  Research  Center  Workshop  on  Satellite  Networks: 
Architectures,  Applications  and  Technologies 
Cleveland,  Ohio 
June  2-4,  1998 


Lockheed  Martin  Telecommunications 

Cuftyriultl  tPItrtlb  LocMhmkJ  Mu»1hi  C*M|KMuttu4i 


Interoperability  for  Global  Area 
Network  Systems 


• Goal:  To  develop  standards,  protocols  and  interoperable  network 
architecture  framework  for  seamless  and  transparent  networking  of 
emerging  satellite  network  systems  with  terrestrial  networks 

• Satellite  industry  task  force  (SITF):  SITF  was  formed  in  January 
1995  to  articulate  the  roles  of  satellites  in  the  Nil  & Gil  and  to 
identify  the  barriers  to  achieving  those  goals 

• Primary  recommendation  was  to  form  a standards  and 
interoperability  subworking  group  under  TIA 


Lockheed  Martin  Telecommunications 

UMOUtt  l.ucfcltuod  MuitUi  CotpiMiilkai 
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interoperability  Classification 


• Internetworking  of  stand  alone  system  with  legacy  networks 
of  the  ground  systems 

• Interoperability  of  emerging  multimedia  satellite  systems 
e.g.  satellite  ATM  with  non-ATM  networks 

• Interoperabilty  of  multiple  Ka-band  systems  for  multimedia 
services  with  “intelligent  gateways” 

• Interoperability  of  commercial  systems  with  military 
systems  of  multiple  frequency  bands,  multiple  data  rates 
and  multiple  waveforms 


Lockheed  Marlin  Telecommunications 

OlUUti  LucKtiuuilMdilHi  CtxpudlKXi 


Interconnectivity  with  Legacy  Networks 


SIU  = Satellite  Interlace  Unit 

TIU  = Token  Ring  Interface  Unit  (IEEEB02.5) 

FIU  = FDDI  Interface  Unit  (ANSIx3t0.5) 

EIU  = Ethernet  Interface  Unit  (IEEEB02.3) 

MIU  = MAN  Interface  Unit  (IEEE802.6) 

Lockheed  Martin  Telecommunications 

CuftyiiyJil  totihtS  Ux*htM*J  Matiui  CdpufulkMi 
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Satellite  ATM  Interconnectivity  with 
LANSs  and  MANs 


TTTT 

Elthemet 

AIU  = ATM  Network  Interface  Unil 


Eithernet 


Lockheed  Martin  Telecommunications 
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Satellite  ATM  Interoperabilty  Issues 

• Encoding  Technologies 

• Signaling  protocols  modifications 

- Q.2931,  UNI  4.0,  Q.931 

• Media  access  protocol  design 

- Shared/random 

- DAMA 

• Traffic  Management 

- CAC, 

- Traffic  shaping 

- Buffering/scheduling 

- Frame  discard 
‘ Quality  of  service 

- ITU.  TT.3S6  versus  A TM  forum  definition 

- Frame  based  QoS  definition 

• Voice  over  A TM  over  satellite 

- VTOA  (A  TM  forum  spec) 

• TCP/IP  over  A TM  over  satellite 

- SAC  protocol 

- ABR,  UBR  service 

- Spoofing 

• Video  over  ATM 

- MPEG  2 

■ lAickheed  Martin  Telecommunications 

CojjyiiyM  ustuiHJ  LodOkuxJ  Marlin  Curpuruttun 
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Global  Multimedia  Satellite  Network 
(GLOMS) 


Lockheed  Martin  Telecommunications 

(Jo}tyikyh4  •ultKJti  Luck  hood  M.ului  CotpoMlKM) 
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HUGHES 

COMMUNICATIONS 


GEO  Satellite  Applications  for  Ka-Band 


Jim  Justiss,  Director  of  Systems  Engineering 
SPACEWAY™  Program 

June  3, 1998 


4^-  s f n m r 


Topics 

HUGHES 

CONNIPTIONS 

Satellite  system  constraints 

When  to  use  satellite  ? 

SPACEWAY™  system  concept 

Satellite  services  - video  clips 

SPACEWAY™  business  model 

ft  s p * t e w * r 
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HUGHES 

COMMUNICATIONS 


1.  Modest  data  rate  with  respect  to  terrestrial 
alternatives 

• E.g.,  OC-12,  OC-48,  OC-192  fiber  (622  Mbps,  2.4,  9.6  Gbps) 

• Constrained  by  spectrum,  power,  weight,  terminal  cost 

2.  Not  uninterruptable 

• Due  to  rain  fade,  sun  outage,  etc. 

• Highly  reliable  links  (better  than  99.8  %)  require  backup  technology 

3.  Modest  system  capacity 

• Constrained  by  RF  spectrum 


LLLLlJJjr 


GEO  Advantages  to  Users 

HUGHES 

cowan* 

Cost  of  service  advantage 

' 

* Point-to-point  from  anywhere  in  the  US 

• Especially  for  broadcast  / multicast  applications 

-i.e.,  ‘push’  multimedia,  data,  video 

Terminal  cost  advantage 

• Fixed-pointing,  stationary  beam 

• Small  power  amplifier 

• Low-end  receive-only  terminal 

mcmr 
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GEO  Advantages  to  Business 
Operator 

Capacity  goes  where  return  is  greatest 

• Deploy  regionally  as  markets  develop 

Quick  deployment  to  start  business 

• Technology  leaps  not  required 

• Design,  rather  than  new  technology  development 

One  satellite  to  start  operation 

• Expand  to  multiple  satellites  per  orbit  slot 

Few  gateway  sites  required 
Simple  network  management 

• Simple  routing  - single  node 

• Broadcast  terminal  / interface  software  updates 


HUGHES 

COMMUNICATIONS 


No  Technology  is  Best  for 
Every  Application 


HUGHES 

COMMUNICATIONS 


No  single  technology  is  best  for  every  application 

• Not  GEO 

- Expensive  for  dedicated,  full-time,  point-to-point  leased  line 

- Data  rates  limited  by  spectrum 

• Not  LEO 

- Expensive  for  broadcast  / multicast 

- Data  rates  limited  by  spectrum 

• Not  fiber 

- Expensive  for  broadcast  / multicast 

- Expensive  for  sites  in  low-density  regions 

Choose  technology  appropriate  for  application 


iinmr 
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HUGHES 

COMMUNICATIONS 

Prefer  satellite  vs.  terrestrial  Doint-to-Doint  when 

• Cost  of  terrestrial  link  is  high 

• Quick  deployment  needed 

•Application  has  multicast  / broadcast  nature 

• Occasional  or  intermittent  use,  different 
destinations 

4^-  s p » c t » i r 

SPACEWAY™  System  Concept 

Terminals 


HUGHES 

COMMUNICATIONS 


• Low  cost,  easy  to  install  USAT 
terminals 

•66  cm,  384  kbps  uplink 
•1.2  m,  1.5  Mbps  uplink  • 

•2.5  m,  6 Mbps  uplink 

•100*  Mbps  downlink  ^ 

• Standard  interfaces 

•Bursty  and  constant  bit  rate 
applications 


• Collocated  satellites 

•Spot  beams  enable  small,  low- 
cost  terminals 

•Spot  beams  give  high  capacity 
via  frequency  reuse 


• On-board  routing 
between  beams 


$ r » c m r 
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HUGHES 

COMMUNICATIONS 


ACTS  T1 
terminal  r 


ramu  p.  i 
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Hughes  Research  Labs 
Malibu,  CA 


Internet 


' uplink  terminal 


J NASA 

Lewis  Research  Center 
Oeveland,  OH 


Simultaneous  feed  on  satellite  and  terrestrial  paths 
Unknown  nodes  along  terrestrial  path 

• Lower  received  rate  due  to  packet  losses 
•Larger  delay  due  to  routing/path  effects 


Satellite  Services  - Video  Clips 


HUGHES 

COMMUNICATIONS 


Compare  satellite  path  vs  terrestrial  Internet: 

1.  TCP/IP  on  ATM  via  ACTS  - 1.5  Mbps  video 

• Compare  satellite  vs  terrestrial  (observe  packet  losses) 

2.  Videoconference  via  ACTS  - 1.5  Mbps 

• VIC /VAT  (MBONE  codec) 

3.  Internet  web  browsing  via  ACTS  - 1.5  Mbps 

• HTTP  1.1  via  ACTS  vs  terrestrial  HTTP  1.0  at  50  ms  RTT 

• HTTP  1 .1  via  ACTS  vs  terrestrial  HTTP  1.0  at  100  ms  RTT 

• HTTP  1.1  via  ACTS  vs  terrestrial  HTTP  1.0  with  4 connections  at  100  ms  RTT 

4.  TCP/IP  on  DirecPC  with  cache  layer 

• Cache  hit  vs  retrieval  with  satellite-optimised  protocol  at  400  kbps 

5.  MBONE  via  DirecPC  vs  terrestrial  MBONE 

• DirecPC  - 128  kbps,  0 % errors 

• Terrestrial  < 100  kbps,  30  % errors 

6.  MPEG  video  on  IP  multicast  via  DirecPC  Enterprise  Edition 


shuiii' 
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SPACEWAY™  Business  Model 


HUGHES 

COMMUNICATIONS 


SPACEWAY™  delivers  personal  broadband  service 

• Ubiquitous  access,  quick  installation 

• Low-cost  for  part-time  service 

• ‘Push’  distribution  of  multimedia,  cache  refresh 

• Compressed  video  delivery  capability  - in  real  time 

Service  Goals 

• Applications  flexibility 

- Support  existing  and  future  applications 

• Seamless  interoperability 

- Application  doesn't  know  or  care  about  satellite  path 

• Complement  other  technologies  - e.g.,  ‘push’  for  point-to-point  fiber 

- Bulk  of  traffic  will  be  terrestrial 

Strategy 

• Standards-based,  using  standard  protocol  interfaces 

- For  example,  IP,  ATM,  MPEG,  etc. 

siHitir 
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Overview  of  ATM  Performance  and  QoS 
Requirements  for  Satellite  Systems 


Presented  by: 

Dr.  Enrique  G.  Cuevas 
Technology  Consultant 
Satellite  Communications 
AT&T  - Laboratories 


Tel.  (732)-949-1130 
Fax  (732)-949-3468 
email:  cuevas@att.com 


OUTLINE 


1-  Performance  Objectives  for  ATM  satellite  connections 

2-  Impact  of  satellite  characteristics  on  ATM  performance 

3-  QoS  requirements  of  ATM  services  and  applications 

4-  Techniques  to  enhance  ATM  performance  over  satellite 

5-  ATM  Availability  considerations 

6-  Pending  issues  and  future  work. 


5/2CV98 
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Organizations  Involved  in  the  Development  of 
ATM  Performance  Standards  for  Satellites 

• ATM  Forum:  Traffic  Management  Specification  (TM  4.0) 

• ITU  Telecommunications  Sector:  Study  Group  13 

- Rec.  1.356  “B-ISDN  ATM  Layer  Cell  Transfer  Performance”  (Q14/13) 

- Draft  Rec.  1.357  “B-ISDN  Semi-Permanent  Connection  Availability” 
(Q15/13) 

• ITU  Radiocommunications  Sector:  Working  Party-  4B 

- Draft  Rec.  S.atm  “Performance  for  B-ISDN  ATM  via  Satellite” 

- Draft  Rec.  S.atm-av  “Availability  Objectives  for  ATM  via  Satellite” 

• United  States  Standards  Groups: 

- T1 A1 .3  (Network  Performance  Aspects) 

- US  WP-4B  (Satellite  Performance,  Availability,  Network  aspects) 

- TR34.1  Communications  and  Interoperability  Section  of  Satellite 
Communications  Division  of  TIA. 


Reference  Model  for  an  ATM  Satellite  Path 


Satellite 

System 


ATM  i 
Ifentiinafi  j 
Equipment  - 
or  ATM 
Swtch  ! 


International  Inter-operator  Section  (IIP) 


l ATM 
i Terminal 
-|  Equipment 
• or  ATM 


NOTES: 

•The  satellite  system  may  consist  of  GSO  or  Non-GSO  satellites  and  may  include 
Inter-Satellite  Links  and  on-board  processing  and/or  switching. 

•The  earth  station  includes:  RF/IF  equipment,  modulator/demodulator,  error 
correction,  buffer,  multiplex  equipment  and  appropriate  terrestrial  network 
interfaces.  It  may  also  include  any  satellite-specific  ATM  processing  equipment. 


5/2M8 
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ITU-T  Rec.  1.356 
QoS  Class  Definitions  and 
Network  Performance  Objectives 


I QoS  Classes: 


no  default 

no  default 

4*10-* 

1/day 

10-4 

3*10-7 

none 

default 

default 

default 

10-* 

none 

default 

default 

default 

u 

10-* 

default 

default 

default 

u 

U 

U 

U 

U 

All  values  ara  provisional  and  they  need  not  be  met  by  networks  until  they  are  revised  (up  or  down)  based  on 
real  operational  experience. 


ATM  Performance  Objectives 
Class-1  Services 


CLR 

CER 

SECBR 

CHAR 

CTD 

CDV 


3xE-7 
4xE-6 
1xE-4 
1 per  day 
400  ms 
3 ms 


7.5xE-8 
1.4xE-6 
3.0XE-5 
1 per  3 days 
320  ms  (max) 
Negligible  * 


5/2098 
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•The  objective  for  satellites  with  ATM  OBP  is  for  further  study. 


285 


Performance  Impacts  of  Satellite  Systems 

Satellite  Systems  present  special  challenges: 

• Occasional  burst  errors  could  adversely  affect  the  facility 
performance  and  service  quality. 

•Transmission  delay  (propagation  and  processing)  could, 
under  some  circumstances,  impact  the  following: 

- QOS  of  videoconference  services 

- Efficiency  of  data  protocols 

- Traffic  Management  and  congestion  control  algorithms 


&I3CV9B 
E.G.  C umi 


Translation  between  ATM  Layer  and  Physical 
Layer  Performance  Parameters 


• Mathematical  expressions  for  the 

probability  of  CLR  and  CER  due  to 
burst  errors  has  been  derived,  f 

• Computer  simulations  and  | 

laboratory  test  results  were  | 

performed  to  find  relationship 
between  BER  and  CLR  and  CER. 

• SECBR  can  be  computed  from 
CER  information. 

• CMR  is  difficult  to  simulate  or 

measure.  However,  a f 

mathematical  expression  that  f 
relates  BER  to  CMR  is  feasible.  J 


S2(V96 
E.G.  Cu*v»« 


y 

« CEP 

to*nwd,W 

.RS)  ^ 

— “ CEI 
CEI 

(pradfetarf.w 
{prwSctad.  w 

1 RS)  ' 

«S) 

Bit  Efror  Ratio  (HER) 
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The  Impact  of  CTD  and  CDV 

• The  overall  CTD  results  from  various  sources: 

-Propagation  delay 
-Coding  and  decoding 

-ATM  node  processing  (queuing,  switching,  routing,  etc.) 

• CDV  depends  on  several  aspects  such  as: 

-Traffic  load  structure  (number  of  VPIs,  VCIs) 

-Switch  buffering  capacity  and  mechanism 

-The  number  of  ATM  nodes 

-The  amount  of  internal  switch  operations. 

• ITU-R  WP-4B  needs  contributions  that  describe  the  behavior  of  CTD  and 
CDV  on  typical  satellite  networks. 


Interoperability  Demonstrations 
AT&T-KDD-Telstra  ATM  Field  Trial 


INTELSAT-V 

(180°)^ 


DS4  *»>er 


Salt  Creek 
CA. 


'Shinjuku 


Telstra 
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Techniques  to  Enhance  the  Performance 
of  ATM  over  Satellites 

• Forward  Error  Correction  (e.g.  Reed-Solomon) 
•Selective  Interleaving  (bit  or  byte  interleaving) 
•Adaptive  Power  control 
•Site  diversity 
•Other 


Availability  Considerations  for  ATM  over  Satellite 

A Total  “A  Propagation  x A Earth  Station  x A Spacecraft  x A Congestion 


IE-04 

Ui 

O 

IE-05 

of 

IE-06 

o 

IE-07 

of 

UJ 

IE-08 

ffl 

IE-09 

o 

IE-10 

<3 

tc 

IE-11 

tm 

2 

IE-12 

LU 

IE-13 

.Class-1  CLR  Objective 


0.10%  1.00%  10.00%  100.00% 

Percent  of  Time  (Any  month) 


mkvm 

EG.  Cuevas 


The  availability  due  to  propagation  (Ap)  is  99.96%  of  the  year. 
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Pending  Issues 

Rec.  S.atm  (ATM  Performance) 

• Need  to  specify  performance  measurement  criteria. 

• Describe  available  performance  enhancement  techniques. 

• Describe  impact  on  CTD  and  CDV  of  satellite  specific  ATM 
equipment  used  at  the  earth  stations. 

Rec.  S.atm_av  (ATM  Availability) 

• Evaluate  the  impact  on  performance  from  short  interruptions 
due  to  equipment  failures  (including  ATM-satellite  equipment). 

• Evaluate  the  Mean  Time  Between  Outages  (MTBO) 
characteristics  of  satellite  links. 

•Seek  (from  ITU-T)  a better  definition  of  “availability  due  to 
congestion”  parameter. 


CONCLUSIONS 


• ITU-R  WP4B  plans  to  complete  by  October  ‘98  the  text  of  new 
Recommendations  S.atm  and  S.atm_av. 

•These  recommendations  may  be  updated  in  the  future  as 
more  information  about  application  requirements  becomes 
available  to  WP-4B. 

•Some  Geo-stationary  transparent  satellite  systems  are  now 
carrying  ATM  traffic.  Designers,  operators,  and  users  of  ATM 
satellite  services  will  benefit  from  new  ITU-R  standards. 


5/2CV98 
E.G.  Cu«w»e 
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Future  Work 


•Study  the  impact  of  satellite  systems  with  OBP  and  ISL  on  all 
ATM  performance  parameters. 

•Study  the  availability  characteristics  of  Ka-Band  satellites 
that  are  intended  to  carry  ATM  traffic. 

• Develop  a recommendation  on  Traffic  Management  for  ATM 
networks  that  include  satellite  connections. 

• Update  S.atm  and  S.atm_av  as  new  ATM  satellite 
technologies,  applications  and  services  emerge. 
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ATM  Over  Terrestrial/Satellite  Network  - 
CTD  &CDV  QoS  Laboratory 
Measurements* 

S.  Nawrot,  T.  Saadawi,  E.  Cuevas 

* This  work  was  supported  in  part  by  grant  from  the  U.S  Army  Research  Laboratory  under  cooperative  agreement  DAALO 1-96-2-0002  (ATRIP) 

05/98  - Simon  Nawrot 


ATM  QoS  - Our  Research 

• Scope: 

- Transparent  Satellites  (no  OBP  or  ISL  considered) 

• Goals: 

- Quantify  and  Characterize  CTD,  and  CDV  for  CBR  Traffic 

- Compare  Published  Simulation  and  Field  Results,  for  the  CBR 
Traffic  Case,  with  Our  Empirical  Results 

- Modeling*  CTD  and  CDV 

• Why: 

- Latency  and  Jitter  as  well  as  CLR  and  BER  are  the  Major 
Impairments  Affecting  Guaranteed  Performance  of  All  ATM 
Networks 

- Relatively  Few  Studies  Examined  CTD  and  CDV  Over  Hybrid 
Terrestrial/Satellite  Networks 

• In  progress 


05/98  - Simon  Nawrot 
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ATM  Service  Categories  - Overview 

VMM  MPEO-2). 
CBR  Ckrcutl  Emulation 

(Vote.). 


Cel!  Delay  and 
Delay  Variation 

Cell  Loss 

Burst 

Tolerance 

Low 

Low 

None 

Low 

Medium 

Some 

High 

Medium 

Some 

High 

Low 

High 

High 

High 

High 

Relevant  ATM  Concepts  - Overview 
Quality  of  Service  (QoS)  Parameters 

Cell  Transfer  Delay  (CTD)  the  end-to-end  delay  a cell  experiences 
traveling  a computer  network  from  source  to  destination. 

CTD,= tA[-  tDI 

Cell  Delay  Variation  (CDV)  or  Jitter 

the  variance  of  CTD,  or  the  variation  in  the  end-to-end  delay  of  two 
successive  cells  of  the  same  stream,  caused  by  queuing  (buffering) 
and  switching,  etc. 

(*AI~  ( Al-l)~  Odi~  tDI-j) 


05/98  - Simon  Nawrot 
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Relevant  ATM  Concepts  - Overview 

CBR  Traffic  Model 


...Cell  Transfer  Delay  CeliAirival  Time 

..  .Cell  In  ter -arrival  Tune  • CDV.l Cell  Delay  Variation  (litter) 

..  .Cell  Departure  Tune  [C77^,/7-  T\ 
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Tested  Network  Topology 
• Hybrid  Network  (Emulated) 

Hybrid  Terrestrial-Satellite  ATM  Network: 


(n-Nodes  & 1-Hop) 


Network  Nodes 


i*z,  a -ifel 


Network  Nodes 


ATMSwitchat 

M 

< SOKKT/TOB  Bate* 


1 - Hop  I »{ 
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Results: 

» Impact  of  the  Channel  Unit  on  CTD  & CDV 

m - Mean,  a - Standard  Deviation 


CTD  - Latenc 


• m-CTD  * f (FG  bandwidth), 

• o-CTD  * f (FG  bandwidth), 


• m-CTD  + RS  Codec  = + 0.2  ms* 

• o-CTD  * f (RS  Codec) 


*atDS-3  rate 


05/98  - Simon  Nawrot 


CDV- Jitter  fa-Cm 


• m-CIT  = f (FG  bandwidth), 

• ct-CIT  « f (1/FG  bandwidth), 


m-CIT  * linear  f (buffer  si 
g-CIT  * f (buffer  size), 


m-CIT  * f (RS  Codec) 
g-CIT  * f fRS  Codec) 


Results: 

• Non-Homogenous  Path  (DS-3  & OC-3) 


“NH-Path”  = (non-homogenous)  link  comprised  of  different  transmission  rates,  e.g.,  DS-3  & OC-3 


CTD  - Latency 

BWMB 

Jitter 

• m-CTD  = f (NH-Path), 

* o-CTD  = f (NH-Path) 

• m-CIT  = f (NH-Path), 

• g-CIT  = f (NH-Path 

05/98  - Simon  Nawrot 
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Summary  and  Conclusion 


*■  CTD  - The  Channel  Unit  contribution  is  negligible  compared  to  the  free-space  propagation  delay;  buffer  size 
is  the  dominant  factor  (50  usee  < CTDmuu  sBuffer/2  <16  ms*  vs.  ~270  ms  far  GEO) 

+ CTD  St  Dev.  - The  Channel  Unit  contribution  is  only  a fraction  of  that  introduced  by  ATM  Switches  (e.g., 

0. 7 usee  vs.  5 usee) 

Jitter 

CDV  - The  Channel  Unit  does  NOT  contribute  to  Jitter.  The  “Jitter-in”  = the  “Jitter-out”  for  every  modem 
configuration  and  feature  used. 

* CDV  St.  Dev.  - The  Channel  Unit  does  NOT  change  the  Jitter  “spread”  either. 

Asymmetry 

v CDV  & CTD  -impacted  by  ATM  cells  transferred  from  one  type  of  framing  structure  to  another  (e.g.,  OC-3 
to  DS-3  or  vice  versa).  The  impact  is  NOT  "symmetrical"  as  it  depends  on  the  mapping  direction. 

Suggestion: 

v The  material  presented  here  may  be  useful  for  the  development  of  ATM  Standards. 

* Similar  Studies  should  be  conducted  for  every  satellite-specific  ATM  equipment  intended  for  use  at  the 
satellite  earth  stations. 

f Further  work  is  required  to  evaluate  the  impact  on  CTD  and  CDV  of  Satellites  with  ATM-OBP  and  ISL 
capabilities  (e.g.,  LEOs  & MEOs). 

* Assuming  modems  with  32  ms  maximum  buffer  depth. 

05/98  - Simon  Nawrot 


Number  of  ATM  Nodes  and  Traffic  Load  vs.  Jitter  and  Delay 
- Terrestrial  ATM  Network  Analysis 


Standard  deviation  of  CTD  (Delay) 


0 10  20  30  40  50  60  70  80  90 


Load  (%Oc3-rate) 


Standard  deviation  COV  (Jitter) 


0 10  20  30  40  50  60  70  60  90 
Load  {%  OC-3  rate) 
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ATM  Performance  Characteristics 


■t  •r-rr. v.Tira  r-f  i snr.  n 
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• CER  Cell  Error  Ratio 

- One  or  more  errors  in  the  payload 

• CLR  Cell  Loss  Ratio 

- Generally  2 or  more  errors  in  the  header 

• SECBR  Severely  Errored  Cell  Block  Ratio 

• CMR  Cell  Misinsertion  Rate 

• CTD  Cell  Transfer  Delay 

• CDV  Cell  Delay  Variation 


Header 


Payload 


40  bits 


384  bits 


MPEG-2  Transport  Stream  Mapping  to  AAL-5 


ftr.;  wrm  rrg  rrrr.t  »i  wn  r*rm 


i i:n,,*-rrrrnr».w-tT^  yrri’mrni  m I 


1 88  Bytes 
Transport  Stream  1 


188  Bytes 
Transport  Stream  1 


1 1 


i ! 


N/A  I Length  | CRC-32 
2 Bytes  2 Bytes  j 4 Bytes 
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PC 

MONITOR 


MPEG-2  ENCODER 
ATM /MUX 


FORE  ATM 
SWITCH 


| MPEG-2  DECODER  f 


VIDEO 

MONITOR 


Tektronix  MST  100 
MPEG-2  Analyzer 


OC3c 

SCRAMBLED  w 

ATM-TO-MPEG-2 

VCI/VPI 

0/101 

DMUX 

VCI/VPI  VCI/VPI 

0/107  0/101 


ADTECH 
AX4000 
ATM  TEST  EQ 


MPEG-2  DECODER  h 


\ MPEG-2  DECODER  [ 


VIDEO 

MONITOR 


VIDEO 

MONITOR 


QPSK 

IF  w 

HP-3 708 A 

IF  ^ 

QPSK 

MODULATOR 

TEST  SET 

DEMODULATOR 

ADTECH  SX/14 
CHANNEL  SIM 


Compressed  Video  Tests  Over  ATM 


* rnrvr.-M’in  nn-.i 


• MPEG-2  Transport  Stream  With  Errors 

- Baseline  without  ATM 

• MPEG-2  Over  ATM  With  Binomial  Errors 

— Digital  Errors 

• MPEG-2  Over  ATM  Over  Emulated  Satellite 

- Analog  Errors 

• Dual  Decoder  Test 

- Variations  due  to  decoder  implementation 

• MPEG-2  over  ATM  Channel  Characteristics 

- QoS  dependence  independently  on  CER  and  CLR 
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Observations  and  Discussion 


■H.T.'TOTtra  i 'iTiTTi  f T3  *)«(1  '.T7«( 


• MPEG-2  requires  a link  quality  of  10-10  BER  or  better 
regardless  of  underlying  protocol. 

• Block  errors  are  far  easier  to  tolerate  than  decoder 
resynchronization 

• Higher  encoding  rates  require  slightly  higher  quality 
links 

• Further  study  is  necessary  in  order  to  determine  the 
relationship  between  the  video  quality  and  the  ATM  QoS 
parameters  - in  particular  between  the  visible  errors  per 
second  and  the  CLR  and  CER  as  well  as  the  affect 
different  CER  and  CLR  distributions  have  on  the  video 


Status  Digital  Video  over  Satellites 


■•f.w.Tniy!  ran  i wr  * rra 


Work  was  completed  in  September  1997  and 
reported  to  ITU-R  Working  Party  4B  and  T1A1.3 
- Paper  is  available  via  anonymous  FTP 

• Site:  ftp.tl.org 

• Directory:  /pub/tlal/tlal.3 

• TIBBS  FILE:  7al30840.doc 
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Proposal 


• ITU-T  Rec.  1.356  Class  I,  stringent  class, 
objectives  for  CLR,  CER  should  be  at  least  1.0E-8 
and  1.0E-7  respectively  in  order  to  acceptably 
carry  such  services  as  MPEG-2  compressed  video 
and  may  require  even  better  performance 


m 


■HI 


ER.CLR  Results  for  45  MBPS  IDR  Modem  ( 
C ompa • ■ with  ::  1062,  proposed  1.356 

lore  stingent  values  are  “FFS"  in  current  draft  of  1.35 
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MPEG-2  Over  ATM  With  Binomial  Errors 


jjfc* 
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MPEG-2  ENCODER 
ATM/MUX 


ADTECH  SX/14 

DS3 

ATM/DMUX 

CHANNEL  SIM 

MPEG-2  DECODER 

VIDEO 

MONITOR 


Purpose 

- Determine  dependance  on  CLR  and  CER 

- Determine  dependence  on  encode  rate 

Conclusions 

- BER  of  1 .OE-8  or  higher  is  definitely  unacceptable 

- Higher  encode  rates  are  slightly  less  susceptible  to  errors 


MPEG-2  over  ATM  Channel  Characteristics 
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NUKO  VF1000D 
DECODER 


VIDEO 

MONITOR 


MPEG-2  ENCODER 
ATM/MUX 


BS3 

HP-BSTS  ATM 
IMPAIRMENT 
MODULE 

FORE  SYSTEMS 
ATM  SWITCH 


VIDEO 

MONITOR 


PlirDOSC  STELLAR  1000  VED] 

* DECODER  MONT 

- Determine  video  

degradation  relative  to  CLR  only  and  CER  only 

Conclusion 

- CLR  has  far  more  affect  on  the  video  than  CER 
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DS3 

MPEG-2  ENCODER  > 

EFData  SDM9000  053 

ATM/DMUX 

VIDEO 

ATM/MUX 

QPSK  MODEM 

MPEG-2/DECODER 

MONITOR 

HP-3 708 A 
NOISE 
TEST  SET 


• Purpose 

- Evaluate  video  quality  when  errors  are  inserted  at  the 
RF  link  (different  CLR  and  CER  distribution) 

• Conclusion 

- Unacceptable  link  quality  at  BER  1.0E-8,  CLR  1.0E-7 
and  CER  1 .OE-6 


MPEG-2  Transport  Stream  With  Errors 
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MPEG-2  ENCODER  \ 


ADTECH  SX/14 

VIDEO 

CHANNEL  SIM 

MONITOR 

Purpose 

- Baseline  MPEG-2  Video 

- Determine  dependence  on  encode  rate  (compression) 

Conclusions: 

- BER  of  1.0E-8  or  higher  is  definitely  unacceptable 

- Higher  encode  rates  are  slightly  less  susceptible  to  errors 
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• Purpose 

- Determine  if  different  decoder  react  similarly  to  errors 

• Conclusion 

- The  two  decoders  tested  degrade  at  thp  same  point 


WartahopM 
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Efficient  and  Flexible  Link 
Enhancement  Techniques  for 
Wireless  ATM 


Yung-Lung  Ho 

yho@yurie.com 
Yurie  Systems  Inc. 

Ian  F.  Akyildiz  & Imvhee  Joe 

ian@ee.gatech.edu,  inwhee@ee.gatech.edu 
Broadband  & Wireless  Networking  Laboratory, 
School  of  Electrical  & Computer  Engineering, 
Georgia  Tech 


issues 

• Bandwidth  efficiency 

• Performance 

- Delay,  Burst  Error,  Random  Error 

• Flexibility 

- Configuration 

- Range  of  application 

- Adaptability  to  link  condition 

- Future  application 

• Cost 

• Manageability 

- Integration  with  switch  or  workstation 
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Summary 

• Per  VC  FEC  maximizes  efficiency,  performance, 
and  flexibility. 

• Yurie  FEC  illustrates  feasibility  of  per  VC  FEC 

- Separate  handling  of  VBR  versus  CBR  (no  FEC 
on  CBR  presently)  traffic. 

- Independent  per  VC  FEC  rate  adaption  depending 
on  link  condition. 

- TCP/IP  operation  down  to  10A-3  BER 

- Trades  some  performence  for  low  cost  implementation  utilizina 
exiting  switch  functions  where  feasible. 

- Integrated  in  the  LDR200  multi-service  switch  platform. 


Per  VC  FEC  Enhances  Efficiency 

Expect  50%  overhead  to  protect  ATM  header  above 
10A-5  BER  with  reasonable  block  error  tolerance. 

Comparison  of  Likely  Header  FEC  Schemes 
(3  Reed  Solomon;  1 standard  ATM  HEC) 

-i-. r-n-rmi r~  , -t — r-  m ,-rr,,  '■  • • * • r[l 


CLR 


BER 


Same  protection  too  expensive  for  some  applications 

- Voice,  Video,  Internet  surfing 
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One  Size  Doesn't  Fit  Ail  Below  T1 


• Random  error  performence  overhead^ 

• Burst  error  performence  °c  overheadAp  * delay 

- 6.6  ms  per  cell  delay  at  64  kbit/sec 

• FEC  scheme  optimized  for  high  speed  links  may 
exceed  delay  requirement  at  low  speed  for  some 
ATM  applications. 


Per  VC  FEC  Maximizes  Flexbility 

• Application  specific  FEC 

- Tie  FEC  to  compression  technique  and  loss  tolerance 

- Postpone  obsolescence 

• Separate  header  versus  payload  FEC  increases 
implementation  flexibility 
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Yurie  FEC's  Multi-Layered  Structure 

• Reduces  cost  and  maximizes  flexibility  by  adapting 
a layered  structure  and  utilizing  switch  resources 

- Switch  architecture  and  existing  ATM  standards  part  of  design 
considerations 


Per  VC  Payload  FEC 
Header  Address  Protection 

(Adress  FEC  or  Redundant  Addressing) 

Cell  Scrambling 
Cell  Delineation 

(ATM  Standard  or  LANET) 

Convolutional/Viterbi  CODEC 

(Recommend  7/8  or  3/4  rate  in  modem) 


OSI 

Layer  2 


OSI 
Layer  1 
(physical)! 


Payload  FEC  for  VBR  traffic 

a)  Per  VC,  accumulate  cells  for  form  group 

(i)  1/2  rate:  1 cell  / group 

(ii)  3/4  rate:  3 cells  / group 

(iii)  7/8  rate:  7 cells  / group 

b)  Extract  payload  and  segment  into  6 blocks. 

c)  Add  one  piggyback  byte  per  block  for  signaling  (adaption)  and 
PTI/CLP. 

d)  Reed-Solomon  encode  each  block  (3  byte  correcting). 

(i)  1/2  rate:  9 bytes  ->  15  bytes. 

(ii)  3/4  rate:  25  bytes  ->  31  bytes. 

(iii)  7/8  rate:  57  bytes  ->  63  bytes. 

e)  Interleave  (6  way  ->  18  byte  burst  tolerance)  and  reassemble 
payload  for  output. 

f)  Load  delineation  byte  to  separate  group. 
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Reed-Solomon(15,13)  coding  over  address  field. 

(a)  Hi -Noise  UNI  (2  nibble  correcting,  255  VC) 


(b)  Hi -Noise  NNI  (2  nibble  correcting,  4K  VC) 


+ -1 

| VPI  : 

h + + + 

; Parity  over  3 

+ + ~ 

: VCI 

1 

4- 1 

: 3 nibble  VPI,  VCI 

+ -- +- 

(c)  Lo-Noise  UNI  (1  nibble  correcting,  64K  VC) 


(d)  Lo-Noise  NNI  (1  nibble  correcting  1 Meg  VC) 


Low  Cost  Redundant  Addressing  Option 

• Compatible  with  Header  FEC 

• No  special  hardware  needed  for  switch  implementation 

• For  Hi-Noise  UNI,  costs  385  redundant  address  to 
tolerate  2 random  bit  or  4 bit  burst  errors. 


Standard  Address  Translantion 


Ingress  cell  wi 
errored  VPI,  V< 
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/ 0 / 1 / 2 / 3 / 4 [ 5 / — /12  I --  /20  I --  /28  I — /36  I — /44  | - /52  ] 


(4)  LSN 


(5)  LSN 


(6)  LSN 


Optional  LANET  Framing 

Extends  cell  delineation  capability  down  to  10A-2  BER. 

Firmware  implementable. 

Speed  insensitive. 

+ +~ + + 

|f|8|d|dIt|BIb|  Cell  1 I Cell  2 I Cell  3 I Cell  4 I Cell  5 I 


Cell  45 1 


F:  One  byte  Frame  Header  ■ 0x96 

8:  One  byte  BIP-B  computed  over  the  previous  frame  except  F 

DD:  Two  bytes  Data  Communications  Channel  (DCC) 

T:  One  byte  Transport  Layer  Control  Channel 

S:  One  byte  Sub-Frame  Header  « 0xE8 

BBi  Byte  Stuffing  Control  (default  0xF62B) 
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+ — > j 5 Cell  History  Buffer 


• Declare  LOS  on  2 consecutive  frame  or  sub-frame 
header  plus  5 HEC  errors. 


LANET  Cell  Delineation  State  Machine 

(LOS) 


• Easy  to  find  0xE8  or  0x96  provides  initial  cell 
alignment  (no  need  for  bit  by  bit  HEC  check) 
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Derived  LANET  Performence 

• 2 orders  of  magnitude  improvement  in  mean  time 
between  noise  induced  LOS 

• Can  acquire  sync  quickly  @ BER  10A-2 


Mean  time  between  induced  LOS 


0.0001 


0.001 

BER 


0.01 


Sync  Acquisition  Time 


BER 


Simulation  Model 


• Can  model  mobile  station  via  Doppler  shift 
in  each  path 
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Simulation  Result 


0.0001  0.001  0.01  0.1 

Channel  BER 


• Without  Doppler  effect,  results  close  to  pure 
random  BER  performence  derived  and  tested 


Conclusion 

• Per  VC  FEC  maximizes  efficiency,  performence, 
flexibility  and  can  be  implemented  cost  effectively 


Future  Work 

• Extend  simulation  to  include  mobile  terminals  and 
other  wireless  channels. 
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StarBurst  Communications 

Unsurpassed  in  Information  Delivery  — 

fast,  efficient,  and  guaranteed 


Reliable  Multicasting  over 
Satellite:  Issues  & Applications 

Satellite  Networks:Architectures,  Applications,  & 
Technologies  Workshop,  June  2-4,  1998 

Ken  Miller,  CTO 


www.starburstcom.com 


Satellite  is  an  Ideal  Transport  for 
Multicast  Applications 


Landline  networks  can  have  complex  trees 


NASA  Shuttle  Video  Distribution  Tree 


Sat.  Workshop  2 
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Many  Flavors 


• Thus,  multicast  does  NOT  mean  multimedia 

Real-time 

Non-real-time 

■ Video  server 

• Replication: 

Multimedia 

• Video  conferencing 

• Internet  audio 

• Multimedia  Events 

• Video  & web  servers 

• Kiosks 

• Content  delivery 

• intranet  & Internet 

• Stock  quotes 

• News  feeds 

• White  boarding 

• Interactive  gaming 

• Data  delivery 
• Server-server 

Data-only 

• Server-desktop 

• DB  replication 

• SW  distribution 

Sat.  Workshop  3 
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Reliable  Multicast  Requirements 


App.  Type 

Latency  Req. 

Reliability 

Collaborative 

Low 

Semi/strict 

Message  Str. 

Low  /medium 

Semi/strict 

Bulk  Data 

Not  real  time 

Strict 

StarBurst 
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Handle  Multicast  Applications 


TCP  is  unicast  only;  thus,  multicast  operates 
over  UDP 

UDP  provides  only  minimal  transport  layer 
services 

- Error  detection 

- UDP  port  multiplexing 

Solution:  specialized  transports  needed  to 
be  added  at  application  layer  to  support 
multicast  application  StarBi 
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Reliable  Multicast  Protocols  are 
not  yet  Standardized 


• Being  studied  by  Reliable  Multicast 
Research  Group  in  IRTF 

- IRTF  recommends  technique(s)  for  a working 
group  in  IETF  to  use  in  standards 

• Problems  considered  hard  - especially, 
methods  to  provide  congestion  control  and 
“fairness”  to  TCP 

• Scaling  and  coping  with  different  network 

infrastructures  also  important  « 
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Protocols  do  not  Scale  Over  Satellite 


Focused  on  terrestrial  routed  networks 

- Today’s  mainstream  Internet 

Many  depend  on  “local  repair”  and 
hierarchy  for  scaling 

- Do  not  have  a place  in  satellite  (except  when 
there  are  terrestrial  network  extensions) 

Others  depend  on  routed  infrastructure  for 
scaling 
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Current  Prominent  Reliable 
Multicast  Protocols 


• Scalable  Reliable  Multicast  (SRM) 

- Favorite  of  researchers;  used  in  wb  tool  on  Mbone 

• Reliable  Multicast  Transport  Protocol  (RMTP) 

- Developed  by  Bell  Labs/Lucent  offered  in  toolkit 
by  Globalcast 

• Pretty  Good  Multicast  (PGM) 

- Recently  proposed  by  Cisco 

• Multicast  File  Transfer  Protocol  (MFTP) 

- Developed  by  StarBurst  ~ most  widely  use<^targurst 
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• Developed  for  data  conferencing  (wb  tool) 

• 1st  protocol  to  use  “local”  repair 

• All  members  in  same  group 


Sat  Workshop  9 


' Congested  Link 


StarBurst 

Communications 


RMTP 


• Uses  hierarchy  (Designated  Receivers)  to 
gain  scaling 
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Receiver  Designated  receiver  Ack 
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• Depends  on  routers  in  network  infrastructure 
to  provide  scaling 

• Supports  low  latency  applications 


PGM  Rcvrs 


ubriets 
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SRM,  RMTP,  PGM  Focused  on 
Terrestrial  Infrastructures 


. SRM 

- Does  not  work  in  any  asymmetric  network 

• RMTP 

- Depends  on  hierarchy  for  scaling  which  often 
does  not  exist  with  satellite  networks 

• PGM 

- Requires  router  assist  in  infrastructure  to  gain 
scaling,  which  does  not  exist  over  satellite  — a 
flat  network  architecture 
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• Trades  off  latency  for  time  aggregation  of 
NAKs  for  scaling 


Block  3 • 1 

Block  2 ' | Block  1 

, - mpi 

Sender 
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■ psrJrfiC  ISO 


• pgoIfotlOl 
■ psritef:?-00 


Receiver 
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MFTP  Disadvantages 


Targeted  to  file  transfer  applications 

- No  strict  latency  requirement 


However,  operates  with  scaling  in  ALL 
network  environments  including  satellite 
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• Traditional  land  line  routed  networks 

- Internet  model,  highly  meshed  routers 

- Symmetric  links 

• Asymmetric  land  line  networks,  e.g.  cable 

• Satellite  networks 

- Asymmetric  and  high  latency 

- Inherently  multicast  ready 

• Hybrids  of  the  above 
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The  Reliable  Multicast  Situation 


• For  non-real  time  delivery  applications, 
MFTP  is  superior  other  reliable  multicast 
protocols 

- Most  scalable  without  relays  or  requirement  of 
retransmission  from  nearest  neighbor 

► MFTP  only  one  that  works  well  with  satellite 

► Scalable  to  > 10,000  without  relays  or  network  assist 

• MFTP  also  includes  a group  management 
protocol 
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Content  content 
Gui<j£L  Server 


Content  & Group 
Mgmt.  Server 


Receivers 

Broadcast  TV  like  Model: 
Receivers  “tune”  to  content 

Sat.  Workshop  17 


Receivers 
E-mail  like  Model: 
Sender 

determines  gr^ 


Burst 

NICATIONS 


How  do  These  Models  Fit  to 
Applications? 

Broadcast  TV  Model 

StarBurst  Closed  Group 

(Push) 

model 

• Non-critical  content 

• Critical  Content 

• Sender  does  not  need 

• Sender  needs  to 

to  know  content  was 

guarantee  delivery 

delivered 

StarBurst 

Sat.  Workshop  18 
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• GM-US  - 8500  dealers  - car  locator  program,  software  updates 

• Toys  ‘R  Us  - 900+  stores  - business  data,  kiosks,  software  updates 

• Ford  - 6000  dealers  - software  updates,  business  data 

• Promus  Hotels  - 650+  hotels  - reservations,  front  desk  apps 

• Wal-Mart  - 2500  stores  - video  distribution  application 

• Ohio  Companies  - 200  clients  - stock  and  bond  inventories 

• Dow  Jones  - remote  printing  of  Wall  Street  Journal 

• The  Box  - distribution  of  10  GB  MPEG  files  to  100  remotes 

• The  GAP  - 1800  stores  - delivery  of  business  data 
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Conclusions 


• Reliable  multicast  over  IP  multicast  enabled 
networks  provides  ROIs  that  are  no-brainers 

• Satellite  is  ideal  for  offering  multicast 
services 

• Reliable  multicast  enables  new  business 
processes  to  improve  competitiveness 

• Closed  Group  model  essential  for  critical 
information  delivery 
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Organizing  Data  Transmission  for  Reliable 
Multicast  over  Satellite  Links 

Antoine  CLERGET,  Walid  DABBOUS 

I.N.R.I.A.  U.R.  de  Sophia  Antipolis, 

2004  route  des  Ludoles  - BP  93, 

06902  Sophia  Antipolis  Cedex  (Ranee) 


1 Introduction 

Intrinsically  broadcast  communication  channels,  satellite  links  offer  a natural  way 
of  multicasting  data  over  a large  geographical  region.  Using  such  links,  one  can 
benefit  from  an  environment  where  adding  thousands  of  new  recipients  does  not  cost 
anything  in  terms  of  network  resources.  There  are  a lot  of  potential  applications 
such  as  software  distribution,  database  updates,  information  broadcast  (weather 
forecast,  financial  data, . . . ).  However,  some  constraints  are  associated  with  satellite 
links  : first,  for  geosynchronous  satellites,  transport  protocols  must  be  able  to  cope 
with  very  important  delays.  Important  delays  lead  to  a noor  system  reactivity  and 
combined  with  link’s  asymmetry,  or  even  unidirectionality,  feedback  from  receivers 
may  be  quite  difficult  to  implement  efficiently.  Second,  satellite  links,  as  all  other 
wireless  links,  undergo  an  important  Bit  Error  Rate  (BER).  To  lower  that  error  rate 
to  levels  comparable  to  that  of  wired-links,  one  must  add  an  important  link-level 
bit  redundancy,  reducing  the  useful  throughput  of  the  link.  This  could  be  avoided 
if  the  transport  layer  supported  corruption  losses.  The  problem  is  therefore  to  deal 
with  congestion  in  an  environment  where  feedback  is  quite  inefficient  and  losses  are 
not  all  due  to  congestion. 

Having  a very  large  number  of  recipients,  some  receiving  the  data  directly  from 
the  satellite  link,  others  receiving  it  relayed  by  an  antenna  through  the  M-Bone  (the 
best  is  for  each  receiver  to  receive  the  data  from  the  satellite  through  the  closest 
antenna  available),  we  will  suppose  that  we  have  an  important  heterogeneity  of 
paths  leading  to  them  in  terms  of  bandwidth  and  error  rate.  Our  aim  is  to  ensure 
reliable  data  transmission  and  to  minimize  for  each  receiver  its  transmission  time. 

To  match  the  constraints  mentioned  earlier,  as  well  as  scalability  considera- 
tions, we  study  feedback-free  mechanisms,  which  means  that  the  recipients  do  not 
acknowledge  the  data  received.  To  ensure  reliability,  we  must  therefore  adopt  a 
Forward  Error  Correction  (FEC)  technique,  where  lost  data  can  be  recovered  with 
redundancy  packets.  Using  this  high-level  FEC  - i.e.  packet  redundancy  - we  hope 
to  be  able  to  reduce  the  low-level  FEC  - i.e.  bit  redundancy  - on  the  satellite  link 
and  to  increase  the  overall  useful  throughput.  Even  without  feedback,  we  can  bring 
the  failure  probability  as  low  as  we  want  by  transmitting  for  a long  enough  time. 
We  can  make  sure  that  introducing  so  much  redundancy  has  no  impact  nor  on  the 
receivers,  since  they  end  the  reception  as  soon  as  they  have  enough  information, 
nor  on  the  network,  which  thanks  to  pruning,  will  not  relay  the  surplus  of  packets. 
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2 Related  Work 


The  issue  of  reliable  multicast  over  satellite  links  has  already  been  studied,  giving 
birth  to  protocols  such  as  MFTP  [?].  In  MFTP,  the  file  is  transmitted  entirely  on  the 
first  pass,  and  missing  pieces  on  subsequent  passes.  However,  it  considers  that  all 
recipients  receive  the  file  directly  through  the  satellite  link,  and  therefore  does  not 
deal  with  problems  such  as  rate  and  congestion  control,  or  receiver’s  heterogeneity. 
A number  of  other  reliable  multicast  protocols  using  feedback  deal  with  congestion 
control,  by  adapting  the  sender’s  rate  to  the  worse  or  to  a given  proportion  of  the 
receivers  in  reply  to  “congestion  reports”. 

As  outlined  in  Receiver-driven  Layered  Multicast  (RLM)  [?]  (which  does  not 
raise  the  issue  of  reliability)  it  is  interesting  to  use  multiple  multicast  groups  to  deal 
with  receiver’s  heterogeneity.  The  transmission  rate  is  receiver-driven  since  it  is  the 
receiver  that  adjusts  it  to  avoid  congestion  by  joining  or  leaving  one  of  the  multicast 
groups  called  “layer”.  In  [?],  Lorenzo  Vidsano,  Luigi  Rizzo  and  Jon  Crowcroft 
present  a protocol  based  on  FEC  and  layered  multicast  that  uses  little  or  no  feedback 
for  congestion  control  and  error  correction.  However,  our  work  is  focused  on  a 
context  where  we  experience  corruption  losses,  as  observed  on  the  satellite  link, 
and  therefore  we  do  not  make  the  assumption  that  losses  are  due  to  congestion. 
Moreover,  we  propose  another  way  of  organizing  data  within  layers  that  does  not 
impose  an  exponential  distribution  of  rates.  To  mimic  the  behavior  of  TCP,  some 
protocols  that  deal  with  congestion  adopt  a strategy  of  multiplicative  decrease  in 
rate  when  congestion  is  detected,  and  additive  increase  otherwise.  Others  estimate 
the  “equivalent”  throughput,  using  the  relation  between  throughput  and  loss  rate 
for  a TCP  connection  : Throughput  ~ 1 /y/Loss  rate.  These  protocols  are  said 
to  be  ‘TCP-friendly”,  because  they  should  behave  like  TCP  when  confronted  to  a 
congested  network.  For  such  protocols,  an  exponential  distribution  of  rates  leads  to 
a slow  and  imprecise  reaction  to  congestion. 

3 Data  Organization 

To  correct  errors  without  acknowledging  sent  data,  we  introduce  redundancy  within 
sent  packets  : k packets  of  data  are  encoded  into  n packets  in  such  a way  that 
receiving  any  k among  these  n is  sufficient  to  rebuild  the  original  k packets.  Forward 
Error  Correction  gets  more  and  more  efficient  compared  to  retransmit  queries  as 
the  number  of  recipients  grows  since  they  can  all  correct  n — k errors,  eventhough 
these  errors  are  different.  It  is  interesting  to  use  large  values  of  k and  n,  (ideally,  k 
is  the  number  of  packets  in  the  file  to  be  transmitted,  and  n » k).  Unfortunately, 
known  FEC  techniques  for  large  values  of  k and  n are  slow  to  compute.  The  file  to 
be  transmitted  is  therefore  split  into  B “blocks”  of  k packets.  Each  block  is  then 
Tec-encoded”  into  a block  of  n packets.  The  end-user  ends  the  reception  when  he 
receives  k different  packets  from  each  of  the  B blocks. 

In  a totally  feedback-free  environment,  and  even  in  general,  it  is  interesting 
to  manage  receivers’  late  arrival.  In  an  application  transmitting  informations  day 
long,  we  would  like  to  be  able  to  have  users  join  at  any  time  and  receive  the  data 
in  minimum  time.  Given  a reception  window  of  B.k  packets,  we  should  then  have 
k (different)  packets  of  each  block  (Characteristic  Ci).  To  ensure  quick  recovery  of 
lost  data,  we  must  also  have  a good  block  interleaving,  which  means  that  given  any 
reception  window  of  k packets,  we  should  have  a packet  of  each  block  (Characteristic 
C2 ). 

We  send  packets  through  “channels”  at  the  same  rate  and  group  these  channels 
within  the  different  layers,  defining  their  respective  rates.  The  sending  rate  of  a 
layer  is  therefore  proportional  to  the  number  of  channels  sent  on  it.  The  following 
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Block  numbers 


Channel  2 
Channel  3 
Channel  4 
Channel  5 


Layer  I 
Layer  2 

Layer  3 


Layer  4 


Optimal 

channel 


Figure  1:  Block  numbers  of  packets  transmitted  on  the  channels  over  time 


data  organization  tries  to  meet  the  characteristics  defined  above  for  the  B.k  and  k 
packets  reception  windows  (Cy  and  C2),  no  matter  how  many  channels  the  receiver 
is  listening  to. 

The  packet  sent  at  date  t on  channel  number  c is  defined  by  the  pair 

([block  number  &*],  [packet  number  p*])  (fig.  1) : 

• b\  = |B./(c)J  +t  [mod  B]  and  I : x — XX0  6*-2<  l-f  I(x)  = 12^=0 

\ iiMBi 

ofiset 

• p\  is  the  index  the  first  non-sent  packet  in  block  &£. 

The  idea  behind  layered  multicast  is  to  reduce  congestion  by  leaving  some  of 
the  multicast  groups  (“higher”  layers),  pruning  preventing  their  packets  from  being 
forwarded  through  the  bottleneck.  But  for  pruning  to  work,  receivers  behind  a same 
bottleneck  must  unsubscribe  to  the  same  layer.  Recipients  must  then  follow  this 
rule  : To  subscribe  to  layer  Li,  a recipient  must  first  subscribe  to  layer  Li- 1 . 

Whatever  the  data  organization,  meeting  characteristics  C\  and  C2  for  all  re- 
ceivers, or,  in  other  words,  for  all  receivers  to  finish  in  minimum  time  when  there 
is  no  loss  (i.e.  File  size  = B.k/-J2  Subscribed  layers'  rate),  and  to  recover  from 
losses  as  quick  as  possible  (without  feedback),  layer’s  i rate  must  be  a multiple  of 
the  sum  of  layer’s  1 thru  i — 1 rate  : 


i— 1 

3p  £ N,  r*  = p.  r, 
j=i 

This  means  that  the  layers’  rate  distribution  must  be  exponential. 

With  our  data  organization,  a receiver  (possibly  arriving  late)  will  finish  in  min- 
imum time  if  it  listens  to  2m  channels,  m >=  0.  Since  we  do  not  want  to  have  an 
exponential  rate  distribution,  we  must  accept  a slight  overhead  (between  0%  and 
12%  ) when  listening  to  n channels,  n ^ 2 m,  Vm,  and  will  have  an  optimal  receiving 
time  otherwise. 

We  have  therefore  proposed  a data  organization  that : 
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• Is  optimal  for  all  receivers,  whatever  the  number  of  layers  they  are  listening 
to,  if  we  accept  to  have  an  exponential  distribution  of  rates. 

• Is  optimal  for  the  receivers  that  listen  to  a number  of  layers  that,  grouped, 
contain  2m  channels,  m > 0 and  slightly  suboptimal  (overhead  between  0% 
and  12%  ) for  others  if  we  wish  to  be  able  to  set  arbitrary  layer  rates. 

3.1  Detecting  and  avoiding  congestion 

In  standard  transport  protocols  used  on  the  Internet,  detecting  congestion  consists 
in  detecting  lost  packets.  On  a satellite  link,  we  have  bursty  losses,  due  to  external 
factors  such  as  bad  weather  conditions.  When  such  errors  occur,  there  is  no  need 
to  reduce  the  transmission  rate.  This  is  why  it  is  useful  to  be  able  to  distinguish 
corruption  losses  from  congestion  losses.  Moreover,  we  would  like  this  mechanism 
to  work  without  modifying  the  routers  on  the  M-Bone,  which  means  that  it  should 
be  an  end  to  end  mechanism. 

Packet  loss  is  not  a good  congestion  signal.  If  we  consider  that  the  traffic 
generated  by  the  source  is  negligible  in  regard  with  the  total  traffic  induced  by  all 
the  other  users,  variations  of  the  Round  Hip  Time  (RTT)  is  not  a good  congestion 
signal  either  [?].  Using  an  approach  similar  to  that  of  packet  pair  rate  control  [?], 
we  propose  to  send  the  data  as  a series  of  bursts  and  try  to  detect  the  “flattening 
of  the  burst”  as  a sign  of  congestion.  But  we  work  here  in  open  loop  and  there  are 
no  acknowledgments  for  the  sender  to  measure  delays.  It’s  up  to  the  receiver  to 
measure  congestion.  Moreover,  with  packet  pairs,  no  measurement  is  possible  when 
one  of  the  two  packets  gets  lost.  Since  the  loss  is  not  in  itself  a congestion  signal,  we 
lose  information  and  therefore  reactivity  when  corruption  losses  are  frequent.  This 
is  why  we  do  not  send  pairs  of  packets  but  bursts  of  b = 8 packets. 

The  position  of  the  packet  within  the  burst  is  included  in  the  packet’s  header. 
Let  D{p)  be  the  inter-packet  delay  preceding  packet  p,  HB  be  the  group  of  packets 
that  are  at  the  head  of  a burst  (i.e.  position  within  the  burst  = 0).  We  evaluate 
the  ratio : 


O = 

Total  Time 

and  use  the  test  Q < threshold,  where  threshold  < 1,  as  a congestion  signal. 
We  then  use  a multiplicative  decrease  - additive  increase  scheme  to  join  and 
leave  layers.  When  the  receiver  has  subscribed  to  layers  1 thru  i,  he  tests  for  a 
congestion  signal 

• after  r<)  received  and  leaves  layer  i if  congestion  was  detected. 

• a^ter  packets  received  and  joins  layer  i+1  if  no  congestion  was  detected. 

N is  chosen  large  enough  to  take  into  account  join  and  leave  delays,  and  not  too 
large  to  have  enough  reactivity. 

4 Conclusion 

When  trying  to  reliably  send  data  to  a large  number  of  receivers  using  a satellite 
link  and  the  M-Bone,  we  face  a certain  number  of  difficulties,  due  to  the  long  delay, 
asymmetry,  and  high  bit  error  rate  of  the  satellite  link,  and  the  heterogeneity  of  the 
M-Bone.  To  solve  the  problem  of  asymmetry,  we  chose  an  a feedback-free  approach, 
replacing  retransmission  requests  with  Forward  Error  Correction,  and  proposed  a 
mechanism  that  enables  receivers  to  detect  congestion  and  then  adapt  their  own 
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Geosynchronous 
satellite 


Source 


Receiver  2 


Figure  2:  Experimental  framework 


receiving  rate.  In  a heterogeneous  environment,  the  data  organization  proposed  here 
enables  them  to  receive  the  data  in  an  almost  optimal  time,  taking  into  account 
late  arrivals,  and  is  still  adapted  to  a good  reactivity  to  congestion  signals.  To 
experiment  these  mechanisms,  we  have  setup  an  experimental  framework  as  shown 
on  figure  (2). 
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Satellite-Multicast  Enhanced 
Consumer  Internet  Services 

Doug  Dillon 


June  3, 1998 


Direct  Broadcast  Satellite  To 
The  Personal  Computer 

New  Media  with  great  potential: 

• True  Broadband,  e.g.  ~30  Mbps  pipe 

324  GB/day 

• Conditional  access  supports  subscription 
services 

• Low-cost  receiver 

• Nationwide  access 

• Installed  base  of  7M  antennas  in  USA  today 
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Critical  Requirements 


• Compelling  Content 

• Ease  Of  Installation 

• Minimal  Impact  On  PC’s  Normal  Use 


Hugh**  Proprietary  II 


New  Medium  Chicken  And  Egg 
Content  Problem 

Can’t  get: 

• subscribers  without  content 

• content  without  subscribers 


You  need  about  ~1M  subscribers  to 
interest  content  providers  in  creating 
custom  content. 


Hughta  Proprietary  II 
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Solution:  Repurposing  Existing 
Content 


Medium 

Radio 

Television 


Cable  TV 


Content 

Repurposed 

Custom 

Music,  Newpaper,  Plays 
Radio  series,  Sports, 
Movies 

TV,  Movies,  TV-reruns 
Cable  TV 

SeriesrGunsmoke,  Sports... 
Mini-series,  Sit-com, 
talk-show... 

CNN,  Weather  Channel 
Pay-Per-View  Movies 

Hugh**  Proprietary  II 


Repurposable  Content  For 

DBS  PC  “ 

Content  Type 

{Good  Initial  Candidate? 

Issues 

DBS  Video/Audio 

Hardware  Cost/Installation/Value  Add  : 

Data  EnhancedVldeo 

Hardware  Cost/Installation/Content 

Web  Sites 

; V Advertising,  Dynamic  Content 

Usenet  News 

V, 10-15  GB/day 

Software  Downloads 

V:  Selecting/Licensing 

IP  Video/Audio 

Content  availability/licensing 

6P0000 

6/19/M 

Hugh**  Proprietary  u 
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DBS  PC  Initial  Service  Package  — * 

Service  Package  Which  Supplements 
Dialup  Internet 

• WebCast  - subscribe  to  name-brand 
web-sites. 

• Usenet  NewsCast  - access  to  the  entire 
Usenet  newsfeed. 

• Software  Downloads  - shareware,  etc. 

• Email  Alert  - notification  when  email 
has  been  received 

Many  different  opportunities  for 
package/bundling  with  other  services. 


Hughu  Proprietary  II 


Critical  Building  Blocks 


• Conditional  Access  Protected  IP  Multicast 

• Conditional  Access  Integrated  Multicast  File 
Transfer  Protocol 

• Efficient  hardware  filtering 


Hughes  Proprietary  II 
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WebCast  Value  Proposition  — 

• Value  Proposition  To  Web-Site 
Operators: 

- “Sign  here  and  you’ll  get  more  hits”  OR 

- “Sign  here  and  turn  your  site  into  a true 
broadband  experience” 

• Value  Proposition  To  Users: 

- “No  hassle  web-content  at  hard-disk 
speed  without  tieing  up  your  phone  line” 

- seamless  transition  between  cached  and 
interactive  content 


HufpMa  Proprttfcry  II 


WebCast  Critical  Requirements  — 

• Content  Integrity  - user  is  given  a 
consistent  snapshot  of  a channel 

• Usability  - must  not  interfere  with  normal 
PC  use 

• Usage  Reporting  - to  sustain  an 
advertising  based  business  model 

• Electronic  Program  Guide  - to  promote 
content,  allow  easy  access  to  all  services 
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Channels,  Packages  Architecture  — - 

• Channel  - typically  a web-site.  Set  of  frequently 
updated  content.  User  subscribes  to  a channel 

• Package  - a subset  of  a channel’s  content. 
Contains  a header,  hash  table  and  the  URLs. 

• Base  Package  - contains  a complete  snapshot 
of  a channel.  Typically  broadcast  overnight  with 
occasional  rebroadcasts  throughout  the  day 

• Delta  Package  - contains  just  what  has 
changed/been  added  since  the  previous  Base 
Package 
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Channels,  Packages  Benefits  — 

• Operates  over  any  multicast  file 
transfer  transport 

• Always  presents  user  with  a 
consistent,  complete  channel 

• Minimizes  impact  on  webcast  receiver 
resources 

• Minimizes  satellite  bandwidth  - some 
really  great  things  you  can  do  with 
compression 

• Allows  a receiver  to  be  brought  quickly 
back  up-to-date 


Hugh**  Proprietary  H 
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Channels,  Package  Architecture  _3a- 
Minimizes  Receiver  Impact 

• Uses  multicast  file-transfer,  very  efficient 
(no  bulk  filtering  in  the  PC) 

• No  preparation  prior  to  accessing  content 
(breaking  it  into  individual  URLs) 

• Individual  Compression: 

- uses  less  disk  space 

- decompression  happens  when  user  is 
accessing  content 

- only  URLs  accessed  are  decompressed 
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Base/Delta  Packages  Minimizes  _ 
Receiver  Impact 

• Base  packages  can  be  scheduled  for 
when  the  PC  is  idle  (overnight) 

• Delta  packages  are  much  smaller, 
inherently  less  impact 

• User  can  turn  off  multicast  file  transfer 
receiver  (for  games)  and  quickly  be 
brought  back  up-to-date  via  delta 
packages 
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Electronic  Program  Guide 

• A channel  everyone  is  subscribed  to 

• HTML/CGI  Based  -content  changes 
with  no  programming 

• For  all  services,  supports: 

- promotion, 

- subscription, 

- launching  of  the  service. 
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WebCast  Receiver  Functions  — 

• HTTP  Proxy 

• Web-Server  For  Local  Processing 

• Automatic  browser  configuration 

• Phone-line  control  on  cache-miss 

• Disk  space  management  - each  channel  has  a 
budget.  Total  budget  is  never  exceeded 

• Channel  subscriptions  - conditional  access 
transaction  for  “premium”  channels 

• Usage  reporting  - piggybacks  Internet  access, 
middle-of-night  as  fall-back 


Hugham  Proprietary  ll 
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NewsCast  Overview  — 

Usenet  News  consumes  40%  of  DirecPC  traffic. 

30%  of  DirecPC  users  are  “heavy”  Usenet 
users. 

Traffic  categories: 

• Music 

• Software 

• images 

• Discussion  groups 

Usenet  News  - 10  to  15  GB/day,  1.4  Mbps 
No  retransmissions 
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Personal  News  Server  — 

• interacts  with  user  to  define  newsgroups  of 
interest 

• efficiently  stores  only  articles  of  interest 

• expires  articles  based  on  age  and/or  disk  space 

- operates  as  a news  server  to  an  unmodified 
news  client 

• relays  postings  through  dialup  to  news  server 
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• Integrate  with  WebCast  by  offering 
download  channel  - with  a few  different 
shareware  offerings  on  a daily  basis 

• Software  vendors  will  pay  for  premium 
placement  with  sufficient  subscribers 

• Overnight  multicast  file  transfer  of 
other  software  downloads 

• For  non-shareware  software,  send 
encrypted  software  which  is  decrypted 
via  Internet  E-Commerce  transaction 
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Email  Alert  — 

Requirements: 

• Notification  within  a few  minutes  of 
email  receipt 

• Must  recover  from  PC  outages 

• Anonymity 

• Low  bit-rate  (<  1 bps/mail  account) 

One  solution: 

• Periodic  multicast  of  cryptographically 
protected  timestamp 
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Installation  Issues 


Low  monthly  service  charge  requires 
low  equipment  cost,  easy  installation, 
low  support  costs 


“PlugNPlay”  PCI  adapters  are  not  easy 
enough  for  the  low-end  consumer 

Target  retail  price  should  be  similar  to 
previous  high-end  modems  (<  $200) 


Hughes  Pro  pristary  II 


Universal  Serial  Bus  Receiver  — — 

• Available  with  all  recent  (1997  or  newer) 
desktop  PCs. 

• Available  with  many  current  laptop  PCs. 

• PlugNPlay  without  opening  the  PC. 

• Adequate  throughput  for  data  applications  (up 
to  4 to  5 Mbps). 

• Supported  by  Win95  OSR  2.1  (1997  or  new  PCs) 

• Fully  supported  by  Win98 

• Not  supported  by  WinNT  until  NT5.0 


Hughs*  Pro  postary  II 
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Conclusion:  The  Time  Is  Ripe 


Each  of  the  critical  requiresments  can  be 
satisfied: 

• Content  - repurposed  Internet  content 
initially 

• East  Of  Installation  - use  existing 
dishes  + USB  receiver 

• Minimal  Impact  On  Receiver  PC  - w/2nd 
generation  applications 


Koghw  Proprietary  I! 
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Integrating  Satellite  Networks  with 
Internet  Multicast  Backbone  (MBone) 


Yongguang  Zhang  and  Son  K.  Dao 
HRL  Labs,  (formerly  Hughes  Research  Labs.) 


email:vaz@hrl.com 
http://www.wins.  hrl.com/people/ygz 


What  is  MBONE? 

A ( virtual ) backbone  network  that 
provides  datagram  routing  services  for 
multicast  applications  over  Internet 
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M'U'in  M ip 
<A.V  iJ.,„  a.ium 
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GEO  Satellite  Makes  the  Best  Internet 
Multicast  Backbone  (MB ONE) 

Lower  cost 
Fewer  router  states 
Uniform  performance  among  members 


Purpose  of  the  Experiments 

• Feasibility  of  Mbone  over  DBS 

• Performance  comparison  with  current 
Mbone  (over  terrestrial  Internet) 

• How  DBS  may  change  the  way  we  do 

- multicast  routing 

- reliable  multicast 
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Loss  Rat#  C-O 


- over  Mbone:  HRL,  UCB,  UCLA,  Columbia 

- over  DirecPC:  HRL 

- over  DirecPC+Mbone:  UCB 

Sampling  the  Mbone: 

- periodic  Receiver  Reports  from  each  receiver 

- over  30  core  samples  (>  20  min,  RR  freq  < 10s) 

- sample  may  be  skewed 


"uc  l n M 


Loss  Rate  (%) 


#110 
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Center  for  Satellite  and  Hybrid 
Communication  Networks 


Error  Control  for  Satellite  Multicasting 


Daniel  Friedman  and  Anthony  Ephremides 
University  of  Maryland,  College  Park 
{danielf, tony}© isr.umd.edu 


Presentation  Outline 


1.  Multicasting  in  Satellite  and  Hybrid  Networks 

2.  Analysis:  Point-to-Point  Communication 

3.  Analysis:  Point-to-Multipoint  Communication 

4.  Numerical  Example 

5.  Additional  Considerations 
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Each  multicasted  transmission  may  reach  some  of  the  receivers  in  error. 
Problem:  Each  multicasted  retransmission  typically  benefits  few  receivers; 


more  receivers  =?>  less  throughput 


acknowledgements  retransmissions 


Retransmissions  are  directed  only  to  appropriate  receivers; 
greater  throughput  possible  than  in  a satellite  network. 
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Initial  Analysis  Assumptions 
and  Definitions 


1.  Unlimited  buffer  size,  unlimited  window  size;  ideal  selective-repeat  ARQ  protocol. 

2.  All  acknowledgements  are  delivered  without  errors. 

3.  Satellite  channel  frame  error  rate  = ps. 

Terrestrial  channel  frame  error  rate  = p,. 

4.  ARQ  information  frame  = { h header  (overhead)  bits  ; f information  bits  }. 

(Same  composition  for  satellite  and  terrestrial  transmission.) 

5.  Bandwidth  consideration; 

Satellite  channel  transmission  rate  = r3  > rt  = terrestrial  channel  transmission  bit  rate. 

6.  In  the  hybrid  network,  all  retransmissions  are  sent  terrestrially. 

7.  Acknowledgements  are  sent  only  for  frames  received  without  errors. 

8.  Performance  measure: 

throughput,  v = E [#  information  bits  transmitted  successfully/s] 
Related  quantity  (primarily  for  pure-satellite  networks): 


(1  = E 


# frames  sent/s 
# frames  delivered/s 


measure  of  “inefficiency” 


Analysis  for  Point-to-Point 
Communication 


Satellite  System: 


OO 

inefficiency  = /?  = £i(l  = 

i=i 


1 

1 -P» 


throughput  = i '^tetuu  = 


(1  - Ps)r , 


Hybrid  System 

— assuming  terrestrial  link  can  accommodate  all  retransmissions: 


^hybrid 
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Acknowledgement  traffic  rate: 


n > K«*(e  + h)0-  p^  + Kack  (e  + h)  Ps 
= Kack  {l+h) 

where  Kack  = average  acknowledgement  length  in  bits  (hybrid  network). 
Retransmission  traffic  rate: 

OO 


at 


Average  Acknowledgement  Length 
(Hybrid  Network) 


Acknowledgement  = 


where: 


{ hone  error-detection  bits  ; hseq  bits  per  sequence  number ; [ haeq  ■ ■ ■ ; ] } 


Kack  — 


hCRC  + + ^ [^  + T.  + T,  + p(  (^  + 2 r«) 


lae9rt(e+h) 


OSS) 


ra  = one-way  propagation  delay  through  satellite  channel 
rt  = one-way  propagation  delay  through  terrestrial  channel 
u)  = maximum  possible  number  of  transmission  attempts  possible  for  a frame 
without  exhausting  ARQ  window  (w  e {1,2,...}) 


Also:  The  ARQ  window  size,  N,  is  given  by: 


\ \(t  + h , , ck  (l+h  . , Kack  , 

- ) 1-  Ta  -| h Tt  + (U>  — 1) h Ti  -I h Tt 

1/  \ ra  Vt  J V n vi 
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1.  M > 1 receivers. 


2.  Noise  processes  on  the  satellite  link  are  independent  and  identical  for  all  receivers. 

3.  Noise  processes  on  the  terrestrial  link  are  independent  and  identical  for  all  receivers. 

4.  No  competition  for  accessing  the  acknowledgment  channel. 

5.  Both  terrestrial  and  satellite  propagation  delays  are  common  to  all  receivers. 

6.  The  transmitter  maintains  a history  of  which  stations  have  acknowledged  which  frames. 


Analysis  for  Point-to-Multipoint 
Communication 


Satellite  Network: 


Pr{A  frame  is  delivered  to  M receivers  with  < j transmissions} 
(i  ~(psY)m 


inefficiency  = pM  = £.7  [7  O')  - l{j  - 1)] 
j= i 


throughput  = Satellite  = (j~^J 


Hybrid  Network: 


V M , hybrid  ^ hybrid  ' 
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1.  r3  = 1536000  b/s;  rt  = 33600  b/s. 

2.  h — 32,  £ — 2176  for  all  ARQ  information  frames  (hCRc  = 16,  hseq  = 16). 

3.  Satellite  and  terrestrial  channels  modeled  as  binary  symmetric  channels  (BSCs)  with  crossover 
probabilities  (BERs)  qa  and  qt,  respectively. 

qa  = [10-7, 10-3]  ; = 1 — (1  — qa)t+h  = [2.2  x 10~7,8.9  X 10-1] 

qt  = (discussed  below)  ; pt  = 1 — (1  — qt)t+h 

5.  u>  = 3.  (Note:  require  u;  > 2 for  efficient  SR-ARQ  operation.) 

6.  Ta  = 300  ms;  rt  = 125  ms  (includes  95  ms  modem  processing  delay*). 

7.  Infinite  sum  for  Pm, satellite  approximated  by  truncating  at  the  minimum  j such  that  7 (j)  > 1 — 10-7. 

•Result  from  an  ACTS  experiment. 

Numerical  Example:  Results 


1.6 
1.4 
1.2 

p—i 

C/3 

I 10 

0.4 
0.2 
0.0 

le-07  le-06  le-05  le-04  le-03 

Satellite  Channel  BER 
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Applicability  of  Hybrid  Network 


Acknowledgement  traffic  rate: 

Kack  < (£  + h)—  — 48.3 


(with  formula  for  KaCk)  =*■  Ps  < 2 x 10  2 
(Also:  N « 740  frames) 


Retransmission  traffic  rate: 

Pt<  1 - — Ps  » 1 - 45.7  ps 
n 

=r-  ps  < 2 X 10  2 


Note:  ps  = 2 x 10  2 =*■  qs  « 10  5- 


=>  Hybrid  network  applicable  for  qs  < 10  5. 


Additional  Considerations 


• Refinements  to  allow  operation  at  higher  BERs 

• Packet  length  (throughput  efficiency  sensitivity;  fixed  vs.  variable) 

• Other  network  topologies  (in  particular,  tree  topology) 

• Wireless  terrestrial  network 

• Hybrid  ARQ 
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Session  6 

Interoperability  Experiments  and 

Applications 
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Applying  Heritage  Internetworking  Solutions  to  ATM  Satellite  Systems 


Dr.  Mehran  Shariatmadar 
Senior  Manager 

SpaceBridge  Network  Corporation 
115  rue  Champlain 
Hull,  Quebec 
J8X  3R1 

Tel:  (819)  776-2848 
Fax:  (819)  776-4179 
Mail:  mshariatmadar@spacebridge.com 

Submitted  to 

The  Workshop  Sponsored  by  NASA  Lewis  Research  Center 
On  Satellite  Networks 

(Architectures,  Applications,  and  Technology) 

June  2-4, 1998 
Cleveland,  Ohio 


Summary 

This  paper  discusses  the  internetworking  of  IP  over  ATM  satellite  systems  as  part  of 
SpaceBridge’ s focus  on  the  development  of  terrestrial  interfaces  and  adaptation  functions 
for  broadband  satellite  systems.  It  gives  an  overview  of  our  heritage  internetworking 
solutions  and  their  potential  for  being  applied  to  ATM  satellite  systems. 


Introduction 

The  unique  networking  characteristics  of  satellites  enjoy  the  strategic  advantage  of 
allowing  widespread  delivery  of  *services  independent  of  geographical  locations  and 
population  density.  They  have  the  advantage  of  jumping  some  of  die  technological  and 
regulatory  hurdles  that  have  so  far  been  preventing  cost-effective  delivery  of  interactive 
broadband  services,  by  terrestrial  means,  to  rural,  small  urban,  and  even  some  densely 
populated  areas  of  the  world. 

The  spectrum  of  satellite  services  can  be  viewed  in  the  context  of  traditional,  new,  and 
emerging  services,  as  shown  in  Figure  1.  High  capacity  trunking  and  broadcast  of  TV 
programming  to  cable  head-ends  and  radio  distribution  are  among  the  so-called 
traditional  services  that  started  in  the  early  70’s.  Although  trunking  is  gradually  being 
replaced  by  fiber,  broadcast  still  remains  the  main  source  of  revenue  for  the  satellite 
industry.  The  so-called  new  services  include  interactive  data  service  for  enterprises 
(VSATs),  direct-to-home  TV  broadcast,  business  television  (BTV),  Internet  access,  rural 
telephony,  and  mobile  voice  and  data  services.  These  services  were  conceived  in  the 
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early  80’ s and  are  now  reaching  the  stage  of  widespread  service  offering  in  the  market 
place.  Broadband  interactive  multimedia  service  to  consumers  and  enterprises  is  among 
the  emerging  services,  and  one  that  has  been  key  in  providing  the  impetus  for 
development  of  on-board  processing  satellites,  the  use  of  frequency  allocation  at  Ka- 
band,  and  increased  inter-operability  with  terrestrial  systems.  These  services  started  their 
development  phase  in  the  early  90’s  and  are  now  being  pursued  at  a very  fast  pace  by  the 
satellite  industry  with  the  expectation  to  reach  the  market  in  the  early  years  of  the  next 
century. 
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Figure  1 : Evolution  of  Satellite  Services 


As  part  of  these  emerging  services  and  to  take  advantage  of  the  fundamental  principles  of 
satellite  communications,  multimedia  satellite  systems,  some  carrying  on-board  ATM 
functionality,  are  emerging  to  complement  the  terrestrial  networks  in  meeting  the 
increasing  demand  for  broadband  services.  These  systems  plan  to  offer  enterprise  and 
consumer-affordable  multimedia  communications  services  to  regions  beyond  the 
economic  reach  of  terrestrial  systems  at  user-perceived  performance  levels  comparable  to 
those  offered  by  terrestrial  systems  (ATM  or  data  services  in  general). 

Convergence  of  satellite  and  terrestrial  networks  is  now  becoming  a key  factor  in  forming 
the  foundation  for  an  efficient  Global  Information  Infrastructure  (GII)  that  is  going  to  be 
supported  by  a wealth  of  information  sources  offered  by  content  providers.  This 
infrastructure  has  to  accommodate  new  applications  with  expanded  communications 
requirements  that  are  creating  an  environment  with  a whole  new  set  of  networking 
challenges.  One  of  the  key  challenges  of  addressing  the  fundamental  tenants  of  this 
global  information  infrastructure  is  the  ability  to  internetwork  efficiently  across  all 
domains.  This  inter-operability  requires  dynamic  and  transparent  connectivity  to  join 
local  and  wide  area,  public  and  private  networks  which  are  characterized  by  a diverse 
mix  of  topologies,  physical  media,  transmission  speeds,  carrier  services,  geographical 
coverage,  interfaces,  etc. 
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ATM  offers  multimedia  services  directly  under  a single  framework  and  has  isochronous 
support  built  in,  and  allows  quality-of-service  guarantees.  However,  until  native  ATM 
applications  are  fully  developed,  a significant  percentage  of  end-user  devices  continue  to 
be  directly  connected  to  legacy  media  such  as  Ethernet  and  Token  Ring.  In  addition, 
because  of  the  unprecedented  variety  of  legacy  applications  and  the  vast  installed  base  of 
related  networks  these  devices  will  continue  to  use  legacy  network  layer  protocols,  of 
which  IP  is  a prominent  example.  This  means  that  the  key  to  the  success  in  the  short  to 
medium  term  lies  in  ensuring  the  availability  of  efficient  methods  to  operate  internetwork 
layer  protocols  over  heterogeneous  networks  that  include  an  ATM  infrastructure. 

The  industry,  including  the  working  groups  of  the  ATM  Forum  and  the  Internet 
Engineering  Task  Force  (IETF),  has  spent  an  enormous  amount  of  effort  in  addressing 
the  internetworking  of  IP  over  ATM.  Also,  a significant  level  of  effort  has  been  spent  by 
the  industry  on  optimization  of  TCP  traffic  for  large  bandwidth  and  long  latency 
applications  over  satellite  networks.  This  paper  considers  IP,  ATM,  and  satellites  in  a 
single  context  and  discusses  internetworking  of  IP  applications  over  ATM  satellite 
systems  as  part  of  SpaceBridge’s  focus  on  the  development  of  terrestrial  interfaces  and 
adaptation  functions  for  broadband  satellites. 

One  example  of  this  corporate  heritage  is  the  Carrier  Scale  Internetworking  (CSI) 
platform,  which  is  an  assortment  of  technology  solutions  for  adding  internetworking 
services  to  the  ATM  multi-services  switching  fabric.  CSI  is  a carrier  class  solution  that 
consolidates  service,  accounting,  and  performance  management  for  IP-based  services  and 
has  many  similarities  in  its  intended  functionality  to  those  of  the  ATM  satellite  systems 
that  have  to  internetwork  with  terrestrial  systems. 

A number  of  topics  will  be  addressed  during  the  course  of  this  paper.  These  topics 
include  requirements  and  criteria  for  internetworking  over  satellite,  routing  of  IP  over 
ATM  in  a satellite  environment,  choices  of  standards  for  carrying  IP  over  ATM,  and  the 
potential  of  CSI  solutions  for  application  to  ATM  satellite  systems. 


2.0  The  Satellite  Advantage 

Before  we  begin  the  topic  of  internetworking  over  satellite,  it  is  important  to  highlight,  as 
shown  in  Figure  2,  where  the  satellite  advantage  lies  in  order  to  keep  those  features  that 
contribute  to  the  competitive  advantage  of  satellite  in  the  foreground.  Awareness  of  these 
features  would  help  ensure  that  they  are  not  compromised  as  alternative  internetworking 
solutions  are  investigated.  The  key  to  increasing  the  satellite  advantage  lies  in  full 
utilization  of  such  features  as  shared  access,  implementation  of  large  numbers  of  nodes, 
dynamic  resource  allocation,  fast  response,  wide  area  coverage,  and,  of  course,  extension 
of  terrestrial  networks  to  rural  and  geographically  unsaved  areas.  These  are  the  features 
that  bring  down  the  cost  per  unit  of  capacity  and  competitively  position  satellite  solutions 
in  the  market  place.  Cost-effective  realization  of  these  features,  particularly  given  the 
scarcity  of  bandwidth  and  space  segment  resources  in  a satellite  environment,  require  that 
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the  overhead  and  signaling  traffic  be  kept  as  low  as  possible.  Internetworking  solutions 
have  to  be  very  conscious  of  minimization  of  overhead  traffic  as  functionality  is 
partitioned  between  the  MAC,  ATM,  and  IP  layers. 
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^ • Wide  area  coverage 

♦ Fastresponse  ^ 


per  unit  of  capacity 


ir^tCeyto  increasing.  v 
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Cost-effective  realization  of  the  features  that  are  key  to  increasing  the  satellite  advantage 
require  that  the  overhead  traffic  to  be  kept  as  low  as  possible 


Figure  2:  The  Satellite  Advantage 


3.0  Inter-networking  Solutions 

3.1  Requirements  and  Design  Criteria 

Internetworking  within  the  scope  of  this  paper  refers  to  transport  of  network  layer 
protocol  (IP  as  an  example)  and  its  related  applications  over  ATM.  The  basic 
internetworking  requirements  include  exploiting  quality  of  service  (QoS)  offered  by 
ATM,  internetworking  with  legacy  equipment,  efficient  transport,  and  expandability  to 
larger  networks. 

In  order  to  optimize  design  criteria  specific  to  internetworking  over  satellite,  it  is  essential 
to  incorporate  an  end-to-end  system  approach  that  takes  into  account  the  unique 
networking  characteristics  of  satellite  as  well  as  terrestrial  systems.  Characterization  of 
realistic  internetworking  applications,  how  they  are  routed  to  the  terminal,  terminal 
interfaces,  media  access  control  (MAC)  options  in  conjunction  with  demand  assigned 
multiple  access  (DAMA),  space  segment  characteristics,  interconnects  to  terrestrial 
networks,  and  the  network  management  entities  are  among  the  elements  to  be  considered. 
The  need  to  have  an  end-to-end  system  perspective  becomes  even  more  critical  when  one 
is  considering  regenerative  satellites  where  terminals,  gateways,  network  management 
entities,  and  the  on-board  switch  are  closely  interwoven  in  their  functionality. 

Insight  into  the  overall  system  is  required  in  order  to  allow  optimum  partitioning  of 
functionality  across  the  network.  How  functionality  is  partitioned  among  the  various 
network  elements  has  a major  bearing  on  the  choices  that  are  made  with  respect  to 
standards  for  carrying  IP  over  ATM,  address  resolution  mechanisms,  QoS,  etc.  These 
elements  include  clients  and  edge  devices  at  the  satellite  terminals  and  gateways,  and 
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servers  at  the  network  control  centers  and  network  operations  center.  In  a satellite 
environment,  the  golden  rule  is  to  minimize  the  ratio  of  over-the-air  routing  traffic  to  data 
traffic  in  order  to  economize  the  scarce  space  segment  resources  and  therefore  bring 
down  the  service  cost  per  unit  of  capacity.  The  trade-offs  in  functionality  partitioning  to 
meet  the  internetworking  requirements  and  at  the  same  time  achieve  an  efficient 
utilization  of  space  segment  resources  is  very  complex  and  has  to  take  into  account, 
among  other  things,  the  functional  entities  in  a satellite  system. 


User  Terminals 
(Level  3 control) 

UT’s  mapping  of  higher 
level  applications  & response 
to  NCC  and  NOC  Commands 


Satellite  Operation 
Center  (Highest  jurisdiction) 

Network  Operation 
Center  ( Level  1 control) 
NOC  Control  of  NCCs 


Network  Control 
Center 

( Level  2 control) 
NCC  control  of  UTs 


Figure  3:  Functional  Entities  in  an  Advanced  Satellite  System 

For  example,  as  shown  in  Figure  3,  the  internetworking  server  functionality  at  the 
network  control  center  (NCC),  can  be  mapped  to  that  of  the  network  operation  center 
(NOC,  also  known  as  master  control  center)  to  reduce  certain  inter-subnet  routing  traffic 
associated  with  address  resolution  enquiry.  However,  it  would  be  at  the  expense  of  larger 
server  functionality  at  the  NOC.  Partitioning  of  layer-3  and  layer-2  functionality  between 
the  edge  devices  and  the  network  is  another  important  factor.  For  example,  layer-3 
routing  capability  can  be  given  to  the  edge  devices  to  query  the  route  servers  and  thus 
ensure  QoS  guarantees.  But  this  could  lead  to  unnecessary  routing  traffic  that  can  be 
dealt  with  differently  in  a satellite  environment.  Within  the  satellite  network,  as  shown  in 
Figure  4,  inter-subnet  address  resolution  does  not  necessarily  require  layer  three  routers 
and  can  be  done  at  the  ATM  and  MAC  levels.  Satellite  inherent  broadcast  capability 
makes  certain  functions,  such  as  multicast,  much  easier.  This  unique  characteristic  of 
satellites  lends  itself  to  modified  internetworking  server  functionality  at  the  NCCs. 
DAMA  is  the  system  arbitrator  that  deals  with  physical  network  resources  that  the  MAC 
layer  would  use.  How  much  functionality  is  given  to  the  network  and  how  much  to  the 
terminal  through  the  MAC  layer  is  an  important  trade-off  consideration  that  does  impact 
internetworking  requirements. 
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Figure  4:  Comparing  a Layer  2 Versus  Layer  3 Functionality  in  an  ATM  Cloud 
(a  Satellite  Model  Versus  a Terrestrial  Model) 


Consideration  of  functionality  partitioning  between  the  satellite  and  terrestrial  networks  is 
also  a critical  element  of  an  end-to-end  system  approach  to  internetworking  solutions.  As 
it  stands  today,  TCP  latency  performance  requirements  necessitate  segmentation  of 
satellite  and  terrestrial  networks  at  layer  4.  This  current  reality,  driven  by  the  limitations 
of  a legacy  layer  4 protocol,  lends  itself  to  partitioning  of  functionality  between  the 
satellite  and  terrestrial  networks  at  the  gateways.  Of  course,  there  is  the  possibility  that 
future  TCP  modifications  would  remove  the  need  for  separate  treatment  of  satellite  and 
terrestrial  links,  and  if  we  further  assume  ubiquitous  deployment  of  ATM,  then  there  is 
no  need  to  make  a distinction  between  the  satellite  and  terrestrial  networks.  Nonetheless, 
irrespective  of  the  latter  happening  in  the  near  future  or  not,  it  is  evident  that  optimum 
functionality  partitioning  is  a two  dimensional  process,  one  involving  the  physical  entities 
including  edge  devices/terminals,  gateways,  terrestrial  interconnects,  NCCs,  and  NOC, 
and  the  other  involving  the  layer  protocols. 

Figure  5 depicts  the  concept  of  distribution  of  functionality  across  protocol  layers  as  a 
function  of  physical  entities.  The  challenge  is  to  determine  how  to  glue  all  pieces 
together  and  achieve  optimum  partitioning  such  that  the  internetworking  requirements  are 
met  with  a minimum  utilization  of  space  segment  resources. 


3.2  Quality  of  Service  (QoS) 

There  are  a number  of  dimensions  to  the  QoS  guarantees  when  it  comes  to 
internetworking  of  IP  over  ATM  satellites.  One  is  to  support  QoS  flows  which  refers  to 
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the  ability  to  establish  a cut-through  connection  in  an  ATM  cloud  between  sub-networks 
and  therefore  position  IP  traffic  to  take  advantage  of  quality  of  services  offered  by  an 
ATM  network.  It  is  worth  noting  here  that  the  QoS  that  is  often  referred  to  in  the 
literature  in  comparing  various  IP  over  ATM  standards  is  this  particular  aspect  of  QoS. 
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Figure  5:  Optimum  Functionality  Partitioning 


The  other  dimension  is  the  flexibility  to  have  various  QoS  options  available  once  the  cut- 
through  is  established.  The  latter  translates  into  the  issue  of  mapping  classes  of  IP  traffic 
(best  effort,  guaranteed,  and  predictive  delay)  to  that  of  ATM  (CBR,  VBR-RT,  VBR- 
NRT,  UBR,  and  ABR).  The  information  for  the  desired  IP  class  of  traffic  can  be 
obtained  from  the  RSVP  (Resource  reservation  protocol)  which  acts  as  the  IP  level 
signaling  protocol  for  QoS.  In  an  ATM  internetworking  environment,  QoS  management 
would  be  limited  to  the  utilization  of  RSVP  as  an  indicator  of  IP  QoS  requirements  that 
can  be  mapped  onto  ATM  QoS.  In  such  cases,  RSVP  is  not  required  to  manifest  its  full 
capability  as  it  does  in  a non-ATM  environment  and  has  to  be  de-coupled  from  its  IP 
network  implications. 


However,  in  a heterogeneous  environment,  the  issue  becomes  more  complex  and  has  to 
be  looked  at  in  the  context  of  how  the  partitioning  of  functionality  is  achieved.  In  a 
heterogeneous  environment  we  have  to  reconcile  the  fact  that  in  ATM,  resource 
reservation  is  made  at  the  connection  setup  time  using  signaling  protocols,  and  thus  is 
sender-driven  and  relies  on  hard-state  in  switches  to  maintain  connections.  Whereas,  in 
the  connectionless  world  of  IP,  resource  reservation  is  not  permanent,  but  times  out  after 
some  period  and  can  be  changed  at  any  time. 
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In  satellite  networks,  QoS  has  another  dimension  and  that  is  the  efficient  utilization  of 
network  resources  when  various  flows  above  IP  are  mapped  into  connections  below  the 
IP  layer.  For  example,  when  one  looks  at  the  classes  of  application  one  sees  quite  a 
variety.  We  can  have  short  duration  UDP  (for  example  DNS  applications),  short  duration 
TCP,  file  transfer,  and  real  time  audio/video  applications.  It  may  be  advantageous  to  use 
a separate  ATM  VC  for  certain  applications  that  are  not  of  short  duration.  There  are 
other  IP  services  such  as  DNS  that  are  ill  suited  for  connection  oriented  delivery  due  to 
their  normally  very  short  duration.  ATM  with  basic  AAL  5 service  is  connection 
oriented  whereas  the  IP  layer  above  ATM  is  connectionless.  At  layer  4 on  top  of  IP,  the 
traffic  is  supported  by  TCP,  which  is  a connection-oriented  protocol.  This  raises  the 
question  as  to  what  degree  it  is  beneficial  to  map  different  flows  above  IP  into  separate 
connections  below  IP.  This  means  that  a mechanism  should  be  in  place  to  ensure  that 
different  ATM  classes  of  services  are  utilized  in  such  a way  as  to  lead  to  an  efficient 
utilization  of  network  resources.  In  the  context  of  efficient  satellite  network  resource 
utilization,  one  should,  at  least,  be  open  to  also  examining  encapsulation  methods  other 
than  “VC  Multiplexing”  and  “LLC/SNAP”.  For  example,  there  are  some  proposals  for 
an  encapsulation  referred  to  “TCP  and  UDP  over  Lightweight  IP”  (TULIP)  which 
assumes  single  hop  reachability  between  the  IP  entities  and  largely  eliminates  IP  header 
overhead. 


3.3  Address  Resolution 

From  an  internetworking  perspective,  a satellite  network  can  be  regarded  as  a single  large 
IP  network.  This  single  network  view  is  realizable  for  two  reasons,  one  is  the  inherent 
satellite  physical  architecture,  and  the  other  is  that  a satellite  network  is  an  autonomous 
entity  governed  by  one  system  of  network  management.  In  a satellite  IP  network  (SIPN), 
by  the  virtue  of  die  features  of  a single  autonomous  network,  there  is  no  need  for  next 
hop  servers  (NHS),  next  hop  resolution  protocols  (NHRP),  or  layer  3 routers  associated 
with  internetwork  communications.  In  addition,  routing  within  the  SIPN  can  be  achieved 
using  purely  ATM  traffic  directly  to  minimize  overhead  traffic.  With  these  principles  in 
mind,  a satellite  implementation  of  IP  address  resolution  can  be  envisaged  as  indicated  in 
the  following: 

1)  Terminal  looks  into  its  IP  routing  table  to  see  if  the  destination  address  is  within 
the  SIPN,  as  shown  in  Figure  6.  If  the  destination  address  is  not  within  the  SIPN, 
the  terminal  searches  the  IP  routing  table  within  its  local  database  for  the 
appropriate  gateway  (this  might  just  be  a default  gateway  for  destinations  not  on 
the  SIPN). 

2)  If  the  destination  address  is  within  the  SIPN,  the  satellite  address  resolution 
process  kicks  in.  If  no  response  is  received,  the  host  is  considered  unreachable 
(either  an  unassigned  IP  address  or  disconnected). 

3)  As  part  of  the  satellite  address  resolution  process,  an  IP  ARP  (MAC  & ATM)  is 
sent  to  the  NCC  server  which  contains  its  own  IP  routing  table.  Note  that,  on 
registration,  the  terminals  have  already  registered  their  ATM  addresses  and  all 
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layer  3 and  MAC  addresses  reachable  through  them  with  the  NCC  server.  The 
NCC  responds  with  the  destination  address  and  then  a direct  VCC  is  established. 
If  the  destination  address  is  outside  of  the  NCC  domain,  the  NCC  could  initiate 
request  for  this  information  from  the  regional  NOC. 

Other  variations  of  this  concept  can  be  thought  of  as  well.  Any  possible  enhancement  to 
the  IP  routing  table  within  the  terminal  that  can  reduce  or  eliminate  the  routing  traffic 
between  the  terminal  and  the  NCC  and  NOC  should  be  considered.  As  can  be  seen,  this 
satellite  implementation  of  the  address  resolution  process  is  simpler  compared  to  standard 
terrestrial  implementations  that  will  be  further  explored  in  sections  3.4.1  and  3.4.2. 


3.4  Choices  of  IP  over  ATM  Standards 

There  are  3 main  standards  that  can  be  considered  for  carrying  IP  over  ATM.  These  are 
classical  IP  over  ATM  (CLIP),  LAN  emulation  (LANE),  and  multi  protocol  over  ATM 
(MPOA).  LANE  and  MPOA  have  been  proposed  by  the  ATM  Forum  and  CLIP  by  the 
IETF.  There  are  also  related  protocols  and  servers  such  as  next  hop  resolution  protocol 
(NHRP)  which  is  used  in  MPOA  (also  in  CLIP  for  inter-subnet  communications)  to 
provide  cut-through  connections  as  well  as  ATM  ARP  queries,  and  multicast  address 
resolution  server  (MARS)  which  is  needed  with  MPOA  for  mapping  multicast  function. 
From  the  point  of  view  of  terrestrial  networks  the  following  attributes  apply  consistently 
with  what  appears  in  most  relevant  literature: 

• Classical  IP  over  ATM  (CLIP):  simple,  limited  to  IP,  limited  to  smaller  networks, 
not  scaleable,  requires  very  large  and  fast  routers,  no  QoS  guarantees  for  inter-subnet 
communications  without  NHRP. 

• LAN  Emulation:  layer  2 bridging  solution,  allows  any  layer  3 protocol  to  be 
supported,  requires  very  large  and  fast  routers  for  inter-subnet  communications,  no 
QoS  guarantees  for  inter-subnet  communications. 

• Multiprotocol  over  ATM  (MPOA):  includes  LANE  for  subnets,  but  allows  inter- 
subnet communication,  distributed  functionality  to  edge  devices,  QoS  guarantee. 

However,  some  of  these  attributes  may  change  their  merits/emphasis,  lead  to  duplication 
of  certain  connection  set-ups,  or  not  fully  apply  in  a satellite  environment.  A satellite  IP 
network  can  be  regarded  as  a single  network  capable  of  providing  ATM  VCCs  anywhere 
within  the  network  including  smaller  sub-nets  within  it.  Therefore,  LANE  and  CLIP  that 
are  conventionally  referred  to  as  not  being  able  to  support  QoS  guarantees  for  inter- 
subnet communications  can,  in  fact,  be  implemented  in  an  ATM  satellite  system  with 
QoS  guarantees  even  without  NHRP. 

A modified  implementation  of  LANE  or  CLIP  within  the  satellite  IP  network  and  perhaps 
MPOA  at  the  gateway  for  interface  to  the  terrestrial  ATM  network  is  a near-to-mid  term 
solution  that  should  be  considered.  However,  MPOA,  or  a modified  version  of  it,  should 
also  be  further  examined  for  implementation  within  the  satellite  network  as  long  as  its 
control  and  data  flows  do  not  lead  to  increased  over-the-air  traffic  in  the  satellite  network. 
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Figure  6:  A Satellite  Implementation  of  Address  Resolution  Mechanism 
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The  higher  software  implementation  complexity  is  something  that  can  be  acceptable  if  it 
is  widely  used  in  the  terrestrial  environment  and  mitigated  by  the  economies  of  scale. 
Further  examination  of  MPOA  for  the  satellite  network  is  warranted  because  of  two 
important  factors.  One  is  that  it  does  offer  additional  advanced  performance  features  and 
the  other  is  the  fact  that  it  is  the  future  inter-networking  protocol  that  is  likely  to  be  used 
by  carriers.  The  latter  attribute  offers  an  advantage  of  strategic  dimension  that  can  not  be 
ignored.  SpaceBridge,  as  part  of  its  in-house  R&D  and  drawing  on  its  extensive  heritage 
in  this  area,  is  currently  looking  at  this  very  issue. 


3.4.1  LANE 

LANE  offers  transparent  emulation  of  LAN  protocols  (currently  Ethernet  and  Token 
Ring  are  defined)  over  ATM  and  as  such  is  a layer  2 forwarding  solution.  LANE 
emulates  a bridged  LAN  on  top  of  an  ATM  network  by  offering  a service  interface  to 
layer  3 that  is  similar  to  existing  LANs.  LANE  allows  all  network  layer  protocols  (layer 
3)  and  applications  to  be  supported  without  any  modifications.  It  is  particularly 
appropriate  for  Enterprise  or  Small  Office  /Home  Office  (SOHO)  type  terminals  that 
usually  feed  into  a local  area  network  of  workstations.  It  requires  fast  routers  for  inter- 
subnet communications  in  the  terrestrial  environment.  QoS  guarantees  are  limited  to  the 
subnet  for  terrestrial  networks.  However  it  is  important  to  note  that  within  the  satellite 
network  QoS  guarantees,  in  so  far  as  establishment  of  direct  ATM  connections  between 
satellite  smaller  subnets  are  concerned,  are  achievable. 

A satellite  implementation  of  LANE,  as  shown  in  Figure  7,  can  be  envisaged  where  on 
one  end  LANE  is  implemented  on  ATM  hosts  (for  example  on  the  ATM  NIC  card) 
forming  an  emulated  LAN  (ELAN)  or  on  LAN  switches  (layer  2 LAN  bridge).  The 
satellite  ATM  terminal  will  include  a LANE  emulation  client  (LEC)  where  LEC  would 
run  the  LANE  protocol  stack  that  performs  encapsulation,  address  resolution,  and  data 
forwarding.  For  the  LAN  section,  the  terminal  LEC’s  user  network  interface  (LUNI)  at 
the  data  link  layer  can  be  attached  to  a bridge  (layer  2)  with  an  RJ  45  interface  for 
external  connection  to  the  LAN.  ’ The  function  of  the  bridge  is  to  avoid  unnecessary 
forwarding  of  packets  that  are  not  destined  for  satellite  routing.  For  the  emulated  LAN 
section  representing  the  ATM  hosts,  the  satellite  terminal  will  have  an  ATM  interface 
(such  as  ATM  25).  Therefore,  LANE  can  be  used  in  two  ways.  One  way  is  as  an 
interface  to  the  LAN  through  a bridge,  and  the  other  way  would  be  to  run  LEC  directly 
on  the  workstation  as  part  of  an  emulated  LAN  where  LEC  provides  a direct  interface  to 
the  upper  layers. 

LANE  servers  for  address  resolution  would  be  located  at  the  NCCs  and  NOC.  All 
routing  traffic  between  the  terminal  and  the  NCC,  and  between  the  NCC  and  NOC  is 
purely  ATM  and  therefore  no  LEC  client  is  required.  However,  at  the  gateway  a LEC 
client  is  required  because  there  is  IP  traffic  involved  heading  for  or  arriving  from  the 
terrestrial  network. 
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A Satellite  Impteimntation  of  LANE 
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Figure  7:  A Satellite  Implementaiton  of  LANE 


With  respect  to  address  resolution,  MAC  and  ATM  address  resolutions  are  separate 
processes  as  shown  in  Figure  8.  The  LEC  transmits  MAC  broadcast  frames  to  the  BUS 
(Broadcast  Unknown  Server)  which  in  turn  transmits  IP_ARP  to  all  its  multicast  nodes. 
The  destination  MAC  address  responding  to  the  BUS  enquiry  is  sent  to  the  source  S’LEC 
which  now  sends  an  LE_ARP  request  to  the  LES  (LAN  emulation  sever)  for  MAC  to 
ATM  mapping.  The  LES  responds  with  an  LEARP  response  with  the  destination’s 
ATM  address  leading  to  the  establishment  of  an  ATM  VCC  to  the  target.  It  is  evident 
that  the  LANE  address  resolution  process  needs  to  be  modified  to  fit  into  a satellite  IP 
network,  particularly  with  respect  to  the  broadcast  mechanism  used  for  the  IP  to  MAC 
address  resolution. 
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Figure  8:  LANE  Address  Resolution  Within  a Subnet 


3.4.2  MPOA 

MPOA  in  effect  integrates  LANE,  NHRP,  and  MARS  to  preserve  the  benefits  of  LAN 
emulation  while  overcoming  the  shortcomings  of  LANE  (i.e.  router  hops  are  required  for 
inter-subnet,  and  inter-network  layer  protocol  communication  over  ATM  VCCs).  In 
other  words,  it  provides  end-to-end  layer  3 connectivity  between  the  hosts  attached  to  the 
ATM  fabric.  An  MPOA  solution  in  the  terrestrial  ATM  environment,  facilitated  by 
NHRP,  would  lead  to  lower  latency  compared  with  LANE  and  CLIP,  by  allowing  direct 
cut-through  across  subnet  boundaries. 

Switching  functionality  is  distributed  in  edge  devices  in  so  far  as  they  query  the  route 
server  for  layer  3 information  and  the  routing  function  is  more  centralized.  MPOA  lends 
itself  to  QoS  guarantees  as  it  allows  mapping  of  specific  traffic  flows  (i.e.  layer  3 packet 
headers  in  RSVP)  to  ATM  connections  with  the  appropriate  QoS.  It  supports  multiple 
clients  and  protocols  such  as  a legacy  Ethernet  host  running  IP  and  an  ATM  attached  host 
running  IPX  or  SNA. 

In  addition,  MPOA  supports  an  efficient  forwarding  function  where  it  overcomes  the 
connection  set-up  latency.  It  consists  of  flow  detection,  temporary  (virtual)  circuit  use, 
and  cut-through  connection.  For  data  transfers  of  short-duration,  a cut-through 
connection  is  not  efficient  because  of  the  increased  inter-nodal  effort  involved  in  the 
address  resolution  process.  Instead,  MPOA  offers  what  is  referred  to  as  the  Default 
Forwarding  function  that  provides  layer  3 forwarding  through  a MARS-based  multicast 
server.  In  MPOA,  a cut-through  connection  is  established  only  when  a certain  flow 
exceeds  a pre-defined  threshold,  such  as  the  number  of  packet  counts.  MPOA  is  a very 
promising  technology  providing  a universal  approach  to  layer  3 protocol  over  ATM 
including  multicast  and  broadcast  and  has  many  advanced  features. 
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A satellite  implementation  of  MPOA  is  possible,  as  shown  in  Figure  9.  The  terminal 
connected  to  a LAN  will  have  an  MPOA  client  that  includes  the  edge  device  capable  of 
forwarding  packets  between  LAN  and  ATM  interfaces.  The  terminal  connected  to  ATM 
workstations  will  only  need  an  MPOA  host  without  the  edge  device.  The  NCC  and  NOC 
will  have  MPOA  servers  and  the  gateway  will  have  an  MPOA  client. 


Figure  9:  A Satellite  implementation  of  MPOA 

With  respect  to  applicability  to  a satellite  network,  an  examination  of  control  and  data 
flows  in  MPOA  would  show  that  there  are  some  functions  that  are  not  needed  or  would 
have  to  be  modified  for  a better  fit  into  the  satellite  network.  In  a wireless  satellite 
network,  the  path  to  the  destination  is  identified  as  part  of  layer  1 and  2 resource 
allocation  and  its  appropriate  utilization  by  the  MAC  layer.  For  example,  MAC  layer 
solutions  for  satellite  networks  include  secondary  access  schemes  that  provide  for  virtual 
circuits  for  short  duration  data  traffic,  a feature  that  is  also  provided  in  MPOA.  In 
MPOA,  traffic  between  an  edge  device  and  an  ATM  host  uses  LANE  as  the  mode  of 
transmission  to  the  default  forwarder  (DFFG)  and  from  there  uses  an  ATM  connection. 
The  DFFG  is  responsible  for  forwarding  traffic  within  a subnet  if  no  client  to  client 
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connection  exists  and  performs  the  multicast  server  function  within  the  subnet.  The  edge 
device,  after  detecting  that  the  flow  qualifies  to  have  a short  cut  support  can  initiate  an 
NHRP  request  to  the  ICFG.  The  ICFG  is  the  IASG  coordination  functional  group,  which 
is  responsible  for  coordination  of  layer  3 addresses  within  the  subnet.  IASG  itself  refers 
to  an  internetwork  address  sub-group. 

Whether  these  functions  would  lead  to  significant  increase  in  over-the-air  traffic  is  an 
area  that  needs  to  be  further  explored.  The  MPOA  address  resolution  process  is  shown  in 
Figure  10  where  NHRP  is  used  as  a cut-through  technique  even  within  a subnet.  Similar 
to  the  case  of  LANE,  the  address  resolution  process  would  have  to  be  modified  to  fit  into 
a satellite  IP  network. 


MPOA  Servers 
DFFG 

S ICFG  D 

Edge  Device  ATM  Host 


Figure  10:  MPOA  Address  Resolution  Within  a Subnet 


3.4.3  CLIP 

CLIP’S  original  definition  is  limited  to  only  IP  and  does  not  intrinsically  offer  multicast 
and  inter-subnet  communications  support  without  MARS  and  NHRP.  Its  address 
resolution  mechanism  may  require  minor  modification  of  the  IP  protocol  stack,  which  is 
not  an  issue  if  implemented  witjiin  the  satellite  terminal.  QoS  guarantees  can  be 
supported  within  the  satellite  network  because  the  satellite  network  is  in  reality  a large 
single  network  that  can  utilize  the  functionality  of  the  NCCs  and  NOC  for  address 
resolution. 

In  one  of  the  CLIP  options  we  can  avoid  the  unnecessary  Ethernet  encapsulation  by 
simply  specifying  the  IP  protocol  layer  as  the  VCs  endpoint  and  place  IP  packets  into 
AAL-SDUs  for  transmission.  This  method  is  referred  to  as  “VC  Multiplexing”  because  it 
involves  terminating  a VC  on  a layer  3 endpoint.  In  this  case,  of  course,  the  traffic  is 
limited  to  a single  protocol  per  VC.  From  a technical  standpoint,  LANE  and  CLIP  are 
very  close,  with  both  being  overlay  models  that  use  ATM  as  a fast  packet  transmission 
system.  In  fact  CLIP  can,  through  LLC/SNAP  encapsulation  allow  any  set  of  protocols 
that  may  be  uniquely  identified  by  the  LLC/SNAP  header  to  be  multiplexed  into  a single 
VC.  In  this  sense,  CLIP  can  be  extended  to  carry  non-IP  traffic  as  well.  A satellite 
implementation  of  CLIP  is  shown  in  Figure  11.  In  addition,  Figure  12  shows  the  address 
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resolution  process  for  CLIP  within  a subnet.  CLIP  lends  itself  well  to  modification  for  a 
satellite  IP  network  because  it  is  a simpler  concept  and  does  not  carry  the  sophistication 
of  other  protocols  such  as  the  MPOA  that  is  designed  to  meet  all  the  internetworking 
requirements  in  a terrestrial  environment.  The  question,  that  needs  more  research,  is 
whether  we  take  a simple  standard  and  build  on  that  to  develop  a version  for  satellite  IP 
networks,  or  a take  a more  sophisticated  model  such  as  the  MPOA  and  modify  it  to  fit  in 
for  satellite  applications. 


ATM  Host  Terminal  Terminal  ATM  Host 

with  CUP  Data  Transfer  in  a CLIP  System  with  CUP 


Figure  11:  A Satellite  Implementation  of  CLIP 
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Figure  12:  CLIP  Address  Resolution  Within  a Subnet 


4.0  Applying  Carrier  Scale  Inter-networking  (CSI)  Concepts  to  Satellite 
Systems 

CSI  is  an  integrated  system  solution,  leveraged  for  satellite  applications  by  SpaceBridge, 
which  meets  all  the  internetworking  requirements  in  the  terrestrial  environment.  It  is  a 
next  generation,  high  performance,  managed  IP  services  infrastructure  that  can  be  used 
by  service  providers  to  differentiate  their  service  portfolio  with  options  such  as  QoS, 
managed  virtual  private  network  services,  and  other  new  value-added  services.  The  CSI 
architecture  consolidates  service,  accounting,  and  performance  management  for  IP-based 
services  by  accomplishing  the  addition  of  IP  services  over  an  ATM  multi-services  core. 
It  interworks  with  the  existing  router  based  IP  networks  using  standard  routing  protocols. 
In  addition,  its  architecture  is  very  scalable  because  the  data  transfer,  routing,  and 
management  functions  are  separated.  It  also  uses  open  standards  that  allow  for  value- 
added  applications. 

CSI  is  of  significant  interest  when  it  comes  to  internetworking  over  ATM  satellite 
systems  because  it  is,  at  a functional  level,  a terrestrial  version  of  internetworking  over 
ATM  satellite  systems.  Consolidation  of  service,  accounting,  and  performance 
management  for  IP-based  services,  scalability  in  terms  of  separation  of  data  transfer, 
routing,  and  management  are  features  that  are  also  required  for  satellite  systems. 
Whether  certain  services  and  design  aspects  within  the  CSI  architecture  are  used  directly 
or  somehow  modified  for  implementation  over  the  satellite,  the  overall  heritage 
experience  and  the  know-how  associated  with  CSI  is  of  significant  advantage  in  shaping 
optimized  end-to-end  solutions  involving  satellite  networks.  The  CSI  network  consists  of 
four  entities  as  shown  in  Figure  13: 

• ATM  network:  corresponds  to  the  ATM  satellite  system. 

• Service  points  (SPs):  access  terminations  with  separate  or  integrated  edge 
forwarding.  This  is  analogous  to  some  of  the  satellite  terminal  functionality. 
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• Routing  services  control  points  (RSCPs):  forward  policy  information  and  support 
routing  protocols.  This  is  analogous  to  some  of  the  NCC’s  level  2 jurisdictional 
functions. 

• NMS:  element,  network,  and  service  management,  similar  to  some  of  the  NOC’s 
level  1 jurisdictional  functions. 

CSI  user  interfaces  and  related  functions  which  include  standards  for  carrying  IP  over 
ATM  can  be  leveraged  for  satellite  applications.  Of  course,  proprietary  adaptation  and 
air  interface  functions  including  provision  of  layer  1 synchronous  access  as  well  as  MAC 
layer  satellite  related  functionality  has  to  be  added  to  replace  the  terrestrial  network 
interface  portion  of  the  CSI  products. 

The  services  provided  by  CSI  include  both  virtual  private  networks  (VPN)  and  public 
Internet.  There  are  multiple  instances  of  these  services  over  a variety  of  interfaces. 
Frame  Relay,  ATM,  PPP  links,  Ethernet,  and  FDDI  LANs  are  examples  of  service 
interfaces  that  are  supported  by  CSI,  most  of  which  are  also  candidates  for  satellite 
terminals.  For  the  VPN  traffic,  the  service  point  (SP)  will  forward  traffic  using  short-cut 
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Figure  13:  CSI  System  Architecture 
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SVCs  between  the  source  and  destination  SPs.  The  ATM  fabric  provides  data  path 
interconnection  of  the  CSI  components.  The  connection-oriented  nature  of  ATM  allows 
for  cut-through  connections  to  be  established  on  demand  by  the  internetworking  layer  and 
the  QoS  features  of  ATM.  An  MPOA  client  is  run  in  the  SPs  to  perform  address 
resolution  for  shortcuts  via  RSCPs.  RSCPs  run  NHRP  to  support  SP-to-SP  short  cuts. 
SPs  maintain  a cache  of  most  frequent  connections  to  minimize  SP-to-RSCP  activity. 
For  public  Internet  traffic,  the  SPs  will  use  pre-provisioned  virtual  connections  to  forward 
traffic. 


5.0  Conclusions 

In  this  paper  we  discussed  the  inter-networking  of  IP  over  ATM  satellite  systems 
addressing  issues  such  as  QoS,  address  resolution  and  routing,  and  standards  for  carrying 
IP  over  ATM.  It  was  highlighted  that  an  end-to-end  perspective  is  required  to  arrive  at 
optimum  partitioning  of  functionality.  The  satellite  broadcast  nature  lends  itself  to 
optimized  solutions  and  therefore  those  inherent  features  must  be  fully  utilized  in  order  to 
maintain  the  satellite  competitive  advantage  in  the  market  place.  When  applied  to 
satellite  networks,  terrestrial  standards  for  carrying  IP  over  ATM  would  need  to  be 
modified/optimized  in  their  server  functionality  and  address  resolution  mechanism.  More 
research  is  required  to  identify  other  areas  for  modifications.  CSI  is  a related  heritage  of 
significant  advantage  for  internetworking  over  ATM  satellites,  whether  certain  design 
aspects  within  its  architecture  are  used  directly  or  somehow  modified  for  implementation 
over  the  satellite. 
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help  to  identify  the  cause  of  performance  problems 

• Combined  traffic  measurements  and  signaling 
message  data  enable  analyst  to  correlate  network 
performance  with  demands  placed  by  the  signaling 


system 
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In  these  experiments  (which  only  had  one 
session  on  the  link): 

• ACTS  satellite  link  introduces  less  than  3 cell 
slot  jitter  in  transmitted  traffic 

• cell  traffic  tends  to  clump  during  transit 
through  the  satellite  terminals  and  on-board 
processor 

• cell  transport  delay  dominated  by  path  length 
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Testbed  for  Satellite  and  Terrestrial  Interoperability  (TSTI) 

A FY98  Program  Product  of  632-50-50  Communications  - Terrestrial 


J.  Patrick  Gary 
Network  Projects  Leader 

Earth  and  Space  Data  Computing  Division/Code  930 
NASA  Goddard  Space  Flight  Center 
pat.gary  @ gsfc.nasa.gov 
301-286-9539 

June  5, 1998 

Presentation  at 

Satellite  Networks:  Archectitures,  Applications,  and  Technologies 

Workshop 


Testbed  for  Satellite  and  Terrestrial  Interoperability 

(TSTI) 


Objective 

Develop  and  demonstrate  high  degree  of  interoperability 
between  satellite-  and  terrestrial-based  networks 

- Develop  and  evaluate  enhancements  to  protocols  such  as  ATM 

and  TCP/IP 

- Test  and  demonstrate  new  interface  equipment  hardware  and 

software 

- Utilize  and  showcase  ACTS  performance,  especially  its  high 

data  rate  capabilities 

- Extend  HPCC  network  research  program  in  Large  Scale 

Networks 

- Open  to  IJ.S.  satellite  and  terrestrial  communications 

carriers,  equipment  suppliers,  and  network  providers 
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Facilitate  and  conduct  research  and  evaluations  of  new 
computer  networking  protocols  and  related 
technologies  which  improve  the  interoperability  of 
satellite  and  terrestrial  networks,  e.g., 

» TCP:  large  windows  (RFC  1323),  SACK  (RFC  2018),  XTP 
(RFC  1453) 

» IP:  TAG  (cisco),  flow  (Ipsilon),  multi-protocol  label  switch 
(IETF),  RSVP,  multicasting,  IPv6 

» ATM:  MPOA,  PNNI,  available  bit  rate  traffic  management 
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ACTS  Experiment  #118 

622  Mbps  Network  Tests  Between  ATDNet  and  MAGIC  Via  ACTS 

Pi's:  J.  Patrick  Gary /NASA  GSFC  & Gary  Minden/DARPA 


2.0  Network  Test  Suites  for  the  ATDNef-ACTS-MAGIC  Network  ( AAMnet ) 

• 2.1  Assessment  of  Satellite  Links  on  ATM  Signaling  (Co-i:  Rich  Veninski/Fore  @ NRL) 

• 2.2  Tuning  TCP  over  High  Speed  Satellite  Links  (Co-l:  Pat  Gary/GSFC) 

• 2.3  Evaluation  of  ATM  Flow  Control  and  Traffic  Monitoring  Techniques  in  a 622  Mbps  Hybrid 
Satellite/Terrestrial  Network  (Co-l:  Victor  Frost/KU) 

• 2.4  Demonstration  and  Evaluation  of  Everyday  Internet  Applications  across  the  AAMnet  at  622 
Mbps  (Co-l:  Pat  Gary/GSFC) 

• 2.5  Demonstration  and  Evaluation  of  TerraVision/ISS  Operating  over  the  AAMnet  (Co-l:  Jay 
Feuquay/HSTX  @ EDC) 

• 2.6  Multimedia  Telemedicine  Applications  Operating  over  the  AAMnet  (Co-l:  Kenneth  Kempner/NiH) 

• 2.7  Telemedicine-enabling  R&D  Testbed  Experiments  Operating  over  the  AAMnet  (Co-l:  Mike  Gill/ 
NLM) 

• 2.8  Testbedding  of  New  Applications  at  622  Mbps  (Co-l:  Pat  Gary/GSFC) 

• 2.9  Native  ATM  Application  Programmer  Interface  Testbed  for  Cluster-based  Computing  (Patrick 
Dowd/NSA  & UMD) 

• 2.10  ARIES  / ACTS  622  Mbps  Experiment  (David  R.  Beering/Amoco) 

• 2.1 1 Multiplatform  Evaluation  of  TCP/IP  over  ATM  Interoperability  Issues  in  a Hybrid  Satellite 
Environment  (Dave  Brooks/Sterling  @ LeRC) 

• 2.12  Assessment  of  Effects  of  Hybrid  Satellite/Terrestriai  Networks  on  ATM  Signalling  (Tom  von 
Deak/LeRC) 


hv,  i a-H  i unei-MAutc  Network  (AAMNET)  Topology  Overview 
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ATDNet  with  Multiwavelength  Optical  Network  (MONET)-  the  system  of  the  future 
Department  of  Defense: 

ATDnet++  ...  A fully  switched  Wavelength  Division  Networking  Testbed 


DARPA 
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INTERNET . 
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Proposed  lute  / 999-2000 : Mixture  of  wavelength 
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Collaborations  /End  Sites  with  GSFC/930 
In  TSTI-based  Evaluations  - Present 
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Testbed  for  Satellite  and  Terrestrial  Interoperability  (TSTI) 
A FY98  Program  Product  of  632-50-50  Communications  - Terrestrial 


• Recent  Major  Accomplishments 

» Enabled  first  use  of  ACTS  high  data  rate  capabilities  by  GUMC, 
KU,  NIH,  and  NLM 

» Monthly  highlights  online  at  http://everest.gsfc.nasa.gov/ 
month.html 

» Charalambos,  C.,  et  al.,  “Experimental  and  Simulation 
Performance  Results  of  TCP/IP  over  High-Speed  ATM  over 
ACTS”,  http://www.ittc.ukans.edu/~ccharala/research.html 
» LeRC  set  ACTS  highwater  throughput  performance 

- 520  Mbps  memory-to-memory 

- 320  Mbps  aggregate  (3  streams)  tape-to-tape 

» Protocol  performance  baselining  by  GSFC 

- TCP,  TCP-SACK,  XTP 

- BER:  0, 10E-11, 10E-10, 10E-9, 10E-8, 10E-7, 10E-6, 10E-5 

- Delay:  0,  5, 71 , 540  ms 
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Trans-Pacific  Digital  Library 
Experiment 


• Demonstrate  and  evaluate  use  of  high  performance  satellite 
communications  and  advanced  data  communications  protocols  to 
enable  interactive  digital  library  data  access  between  the  U.S.  Library 
of  Congress,  the  National  Library  of  Japan,  and  other  digital  library 
sites  at  1 55  Mbps 

» The  satellite  links  demonstrate  effective  use  of  geostationary  satellite- 
based  communications  in  the  Global  Information  Infrastructure 
» The  data  communications  protocols  will  include  both  standard  protocols 
with  recently  specified  options  for  performance  enhancements  and 
experimental  protocols  designed  for  improved  performance 
» Access  will  include  interactive  searches  and  retrievals  of  new  on-line 
digital  library  data,  and  will  promote  an  understanding  of  the  need  for 
ready  access  to  these  data 
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Trans-Pacific  Digital  Library 
Experiment 


U.S.-led  Applications 

• Law  Library  of  the  Library  of  Congress 

» Global  Legal  Information  Network 

• NASA  Goddard  Space  Flight  Center 

» Trans-Pacific  Access  to  GLOBE  Visualizations  in  Real  Time 

• NIH  National  Library  of  Medicine 

» Multi-Lingual  Digital  Anatomical  Data  Base 

• USDA  National  Agricultural  Laboratory 

» Plant  Genome  Databases 


Configuration  of  Networks  for 
Trans-Pacific  Digital  Library  Experiment 


N-STAR  INTELSAT  ACTS 


05/19/98 
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Testbed  for  Satellite  and  Terrestrial  Interoperability  (TSTI) 
A FY98  Program  Product  of  632-50-50  Communications  - Terrestrial 


• Major  Milestones 

» FY98: 

TSTI  development  and  instrumentation; 

Support  for  PI  & Co-I’s  at  GSFC,  KU,  LeRC,  NIH,  and 
NLM  in  622  Mbps  Network  Tests  between  ATDNet  and 
MAGIC  via  ACTS  (Exp.  #118)  and  for  others  (e.gM  GUMC 
and  GIBN  Trans-Pacific  Digital  Library  Experiment) 

» FY99: 

Complete  evaluations  of  IP  switching  and  ATM  traffic 
management  4.0  explicit  rate  control  in  ABR; 
Enable/expand  testbed  for  use  by  other  GIBN  projects  and 
Satellite  Alliance  USA 

» FYOO: 

Initiate  evaluations  of  IP  RSVP  and  ATM  QoS  parameters 

» FY01: 

Complete  evaluations  of  IP  RSVP  and  ATM  QoS 
parameters 

ESDCD  On-Going  Network  Projects 

More  Info 

• AAMNet:  ADTNet-ACTS-MAGIC  Network  (622  Mbps) 

• http://everest.gsfc.nasa.gov/SCTB/AAMNET_plan.html 

• ATDNet:  Advanced  Technology  Demonstration  Network 

• http://www.atd.net/ 

• GIBN  DLE:  Global  Information  Broadband  Network  Dig.  Lib.  Exp. 

• http://dlt.gsfc.nasa.gov/gibn/ 

• GLIN:  Global  Legal  Information  System 

• http://lcweb2.loc.gov/law/GLINv1/GLIN.html 

• HECN:  High  End  Computer  Networking  (for  HPCC/ESS) 

• http://everest.gsfc.nasa.gov/ 

• TSTI:  Testbed  for  Satellite  and  Terrestrial  Interoperability 

• http://everest.gsfc.nasa.gov/TSTI/TSTI.html 
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Satellite  Interoperability 
Issues 

TCP/IP  congestion  controls  with  ATM 
congestion  controls  over  high  data 
rate/high  delay  links. 

- Bandwidth  * Delay  = Buffer 

- Random  Early  Detection 

- Weighted  Fair  Queue 

- ABR  EFCI,  RR 

- RSVP  (Resource  Reservation  Protocol) 

- IP  Precedence 
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S|  Satellite  Interoperability 
gl  Issues 

PNNI  using  SVC  links  over  high  delay 
links. 

- Cell  routing 

- Convergence 

Classical  IP  / LANE 

- Call  setup 

-ARP  server  placement,  LEC/LES/BUS 

- Congestion  controls 


Satellite  Interoperability 
Issues 

DICOM  3.0  standard 

- Generates  high  volumes  of  data. 

- Uses  TCP/IP  as  its  transport. 

- High  speed  data  links  needed. 

- Standard  enables  communication  between 
various  medical  sources  and  users 
(computer  workstations,  MR  imagers,  film 
digitizers,  archives,  etc.) 
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Questions 

Does  TCP/IP  congestion  control  work 
effectively  in  a High  Data  Rate/  High 
Delay  network  ? 

Does  ATM  congestion  control  work 
effectively  with  TCP/IP  congestion 
controls  in  a High  Data  Rate  / High 
Delay  Network  ? 


L Satellite  Interoperability 

Questions  (continued) 

• Does  PNNI  work  effectively  over  a High 
Data  Rate  / High  Delay  Network  ? 

• Does  Classical  IP  have  any  problems  ? 
• Does  LANE  work  over  satellites  ? 

• Does  DICOM  need  some  modifications 
to  work  effectively  over  satellites? 

• BW*D=Buffer,  How  much  is  enough? 
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Expectations 

TCP/IP  congestion  controls  will  work  a 
High  Data  Rate/  High  Delay  network  but 
may  need  to  be  adjusted. 

SVC’s  using  Classical  IP  and  LANE  will 
be  useable  but  possible  some  timing 
parameters  may  need  to  be  adjusted. 

BW*D  will  be  a combination  of 
congestion  controls,  timers,  and  buffers. 


Satellite  Interoperability 
fr  Expectations 

• ATM  congestion  control  and  IP 
congestion  control  interaction  in  this 
environment  is  an  unknown. 

• PNNI  parameters  will  probably  need  to 
be  adjusted  for  the  high  delay  network. 

• DICOM  applications  will  need 
adjustments  for  this  network. 
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Satellite  Interoperability 


uQ* 


Thank  You 
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Session  7 

ATM  over  Satellite  Network 
Quality  of  Service 
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Goals 


mm 
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Traffic  management 
issues  for  TCP/IP  based 
data  services  over 
satellite- ATM  networks 

• Discuss  design  issues  for 
TCP/IP  over  ATM 

- Optimize  the  performance 
of  TCP/IP  over  ATM  for 
long  delay  networks 
Evaluate  ATM  service 
categories  for  TCP/IP 
traffic 
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ATM  Service  Categories  for  Data 

• Unspecified  Bit  Rate  (UBR):  User  sends  whenever  it 
wants.  No  guarantees  made  by  network 

• Guaranteed  Frame*  Rate  (GFR):  User  sends  whenever  it 
wants.  Network  guarantees  a minimum  frame  rate,  and  fan- 
usage  of  excess  capacity.  Needs  frame  delineation  info 

• Available  Bit  Rate  (ABR):  User  follows  network  feedback. 
Network  guarantees  a minimum  cell  rate,  and  fair  usage  of 
excess  capacity.  Network  guarantees  cell  loss  ratio 

• Non-Real  Time  Variable  Bit  Rate  (nrt-VBR):  User 
declares  peak  and  average  rates.  Network  guarantees  cell 
loss  ratio 


Designed  for  best  effort  and  non-real  time  traffic 


Rohit  Goyal.  The  Ohio  State  University 


NASA  Workshop’98 


426 


• Real  Time  Variable  Bit  Rate  (VBR):  User  declares  peak  and 
average  rates.  Network  guarantees  cell  delay,  cell  delay  variation 
and  cell  loss  ratio 

• Constant  Bit  Rate  (CBR):  User  declares  peak  rate.  Network 
guarantees  cell  delay,  cell  delay  variation  and  cell  loss  ratio 


Designed  for  real  time  traffic 
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Satellite-ATM  Deployment 
(Access  Networks) 

(UBR/GFR/ABR)?^^^\ 
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• Queuing:  Single  UBR  queue 

• Buffer  Management 

• Tail  Drop : Low  efficiency,  low  fairness 

• Early  Packet  Discard:  Low  fairness 

• Per-VC  accounting:  High  efficiency,  high  fairness 

• End-system  Policies 

• Vanilla  TCP:  Poor  performance 

• Fast  Retrans.  & Recov. : Bad  for  long  latency 

• Selective  Ack:  Good  performance  for  long  latency 

• No  control  over  sources  =>  Potentially  Large  queues  in 


network 
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UBR  with  Guaranteed  Rate  (GR) 

• Queuing: 

• Single  queue  with  guaranteed  minimum  service  rate 

• Buffer  management:  Same  as  UBR 

• End  system  policies:  Same  as  UBR 

• Improved  performance  of  TCP  due  to  guaranteed  rate 

• Cannot  isolate  traffic  from  different  organizations 

• Will  not  work  for  backbone  networks 

• May  be  OK  for  access  networks 
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Guaranteed  Frame  Rate  (GFR) 

Minimum  rate  guarantee  for  frames 

Complete  frames  are  accepted  or  discarded  in  the  switch 

Traffic  policing  is  frame  based 

Traffic  conforming  to  MCR  is  served  with  low  cell  loss 

Traffic  above  MCR  is  served  as  best  effort 

CLP=0  frames  given  higher  priority  than  CLP=1  frames 

Network  can  optionally  tag  frames  exceeding  MCR 
(GFR.2) 

Good  for  backbone  as  well  as  access  networks 
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Queuing 

Per-VC  FIFO 

Buffer  Management 

Per-VC  Global 

Thresholds  Threshold 

Tag-sensitive  Buffer  Mgmt 

2 Thresholds  1 Threshold 

• Equal  MCR  allocation 

• Can  do  with  FIFO  and  per- VC  thresholds 

• Unequal  MCR  allocation 

• Difficult  to  provide  per-VC  MCR  with  FIFO  for  TCP/IP  traffic 
with  high  MCR  allocation 

• Easy  to  provide  per-VC  MCR  with  per-VC  queuing 


Rohit  Goyal.  The  Ohio  State  University NASA  Workshop’98 
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Queuing:  Single  ABR  queue  or  per-VC  queues 
Feedback  Control: 

• Bit  Based : Slow  control,  bad  for  long  latency  networks 

• Explicit  Rate:  Fast  control,  bounded  buffer  requirements 

• Virtual  Source/Virtual  Destination:  Allows  hop-by-hop  control 
& isolates  terrestrial  switches  from  effects  of  satellite  latency 

Buffer  Management: 

• Less  important  with  a good  explicit  rate  scheme  like  ERICA+ 

• Bounded  buffer  requirements  (Constant  x round  trip  delay  x 
bandwidth)  for  zero  loss  for  TCP/IP  over  ABR 

• UBR-like  buffer  requirements  at  the  edges  of  the  ABR  network 
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UBR 

GFR 

ABR 

No  guarantee. 

Minimum  rate  + fair  excess 

Unfair 

Fair 

Queue  in  network 

Queue  at 
network  edges 

Simple  for  user 

Good  for 
provider 

Same  end-to-end  or  backbone 

Good  if  end- 
to-end  ATM 

Rohit  Goyal.  The  Ohio  State  University 


NASAWorkshop’98 


431 


Summary 

« Design  issues  for  TCP  over  ATM 

• End  system  policies:  Vanilla  TCP,  Fast  Retr.  Recov.,  SACK 

• Feedback  control:  Explicit  rate,  binary,  end-to-end,  VS/VD 

• Buffer  management:  tail  drop,  EPD,  per-VC  acc.,  tag  sensitive 

• Queuing:  Per-Class,  per-VC 

• UBR:  No  guarantees,  poor  performance 

• UBR  w / per-VC  accounting:  Good  efficiency+faimess 

• GR:  Cannot  isolate  different  VCs 

• GFR:  Per-VC  minimum  rate  guarantees 

• ABR:  Congestion  shifted  to  edge  of  network 

• VS  AD:  Isolate  terrestrial  segments  from  satellite 

Rohit  Goyai.  The  Ohio  State  University NASA  Workshop^ 
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ATM  Via  Satellite:  Link  and  Networking  Technologies 


ATM  Via  Satellite: 

Link  and  Networking  Technologies 


■ ATM  Via  Satellite:  Key  Challenges 

• ATM  Over  (point-to-point)  Satellite  Links 

* ATM  Satellite  Networks 


• Conclusions 
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ATM  Via  Satellite:  Key  Challenges 


Providing  Fiber-like  Quality  (Cell  Loss  Ratio  and  Cell  Error  Ratio) 
Time-varying  bit  error  rates  and  bit  error  distribution 

Effect  on  throughput  Performance  due  to  geosynchronous  satellite  delay 
ATM  Traffic  Management,  Congestion  Control 
End-to-end  protocols,  e.g.,  TCP 

Efficient  Bandwidth  Use 

ATM  and  other  ATM  related  protocols  (such  as  ATM  speech)  are  not 
bandwidth  efficient 

Satellite  resources  are  relatively  expensive 
Dynamic  Bandwidth-on-Demand  Concepts 

Meeting  Cell  Delay  Variation  QoS  Requirements 

Satellite  TDMA  framing  can  result  in  unacceptable  cell  delay  variation 
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COMSAT  ATM  Link  Accelerator  - CLA-2000/ATM 


ATM  Access  Port 
DM,  E3,  RS-449, 
(T1.E1.)' 


Provides  fiber-like  quality  over  satellite  links  for  ATM 
traffic 

Improved  BER  (10-9  or  better),  low  Cell  Loss/Error  Ratio 
Cells  protected  using  powerful  Reed- Solomon  coding 
Interleaving  to  combat  burst  errors 

Can  correct  640  bit  burst  error 
Errored  cells  not  delivered 

Bandwidth  Expansion 

Adaptive  Coding  based  on  Measured  Error  rate 
Reed-Sol  omon  coding  overhead  0%  - 7% 

Idle  cells  not  transmitted 

Header  compression  option  (4%  savings) 

Traffic  management 

High  prionty.  Low  litter  for  CBR/VBR  traffic  (e.g.,  video) 
Low  priority,  Large  buffers  for  UBR/ABR  traffic  (e.g., 
LAN  date) 

Lossless  Data  Compression  for  traffic  on  selected  VCs 
2:1  compression  ratio  typical 
Up  to  T1  link  rate 

DS*3,  E3,  RS-449,  (Tf , El)  ATM  Interface 
Satellite  Interface,  RS449,  up  to  8.448  Mbit/s 
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Unique  Framing,  Acquisition  and 
Synchronization  scheme 
Low  overhead 
Fast  Acquisition 

Cali  buffering 

User  configurable  queue  sizes  for 
different  traffic  types 

Header  compression 

Compresses  ATM  header 
Loss-less,  adaptive 
4%  bandwidth  savings 

Transparent  Mode  Option 

Turns  off  Reed-Soiomon  coding. 
Interleaving  and  Compression 

Support  for  Simplex  links 

Support  for  Asymmetric  Rate/Delay  Links 

Support  for  Low  Speed  Links 

Configurable  Interleaver  depth  and 
Reed-Solomon  frame  size 

Support  for  KG  Encryption  units 

Support  for  RS-530  and  V.35  interfaces 


1:1  Redundancy  option  with  automatic  switchover 
Plug  and  Play 

Default  configuration  useable  across  wide 
range  of  link  conditions 

Management  using  local  console  or  remotely  over  IP 
network 

Automatic  self-test  on  start-up 

Diagnostics,  Loopback  capabilities 

Performance  statistics,  link  quality  monitoring 

Configuration  Parameters 
Saved  in  flash  memory 
Console  commands  for  editing 
Factory  configured  defaults 

Front  panel  LCD  display 

Flash  memory  tor  software  storage 

Software  updates  can  be  done  in  the  field 

Sun  workstation  based  tools  for  software  upgrade 
over  ethemet 

Can  also  be  o*ne  using  PC  over  console  port 
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CLA-2000/ATM  Performance  v/s  BER 


ie-o* 
iE-io 
IE-12 
IE-14 
IE-16 
IE-18 
IE-20 

1E-01  IE-02  IE-03  IE-04  IE-05  IE-06  IE-07  IE-08  IE-09  IE-10 


IIKiuMKJKl-l-tf.'nbi 


Bit  Error  Rate  (bursty) 
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Linkway  2000  Service  Features 


ATM  Service 

DS3,  E3  Interface 

Up  to  8 Mbit/s  of  user  data  per  interface 
Support  for  CBR,  VBR,  ABR  and  UBR  traffic 
PVCs  Initially;  SVCs  later 

Packet  Swvico 
Frame  Relay  interface 

Serial  Synchronous  Interface,  64  Kbps  - 2 Mbps 

PVCs  Initially;  SVCs  later 

LAN  Support  using  external  Routers 

Digital  Circuit  Sondco 

Future  Services 

ISDN  PRI  Interface,  23B+D  (T1)f  30B+D  (El) 

ISDN  over  SRI  2B+D  Interface 

Switched  on-demand  nx64  Kblt/a  circuits 

Direct  LAN  (TCP/IP)  connection 

Full  ISDN  signaling  support 

Analog  2W/4W  telephone  interface  with 

SS7  Signaling  support  for  carrier  interconnect 

compressed  voice 

T1/E1  IntorfacM  using  external  converters 


All  interfaces  end  services  concurrently  supported  In  all  terminals! 
Bandwidth  on  Demand  for  all  services 
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Linkway  2000  Key  Product  Features 


Network  Capabilities 

Saleable  Terminal  Sites 

Mum-carrier,  TOMA 

Customer  Premise  Terminals 

Mesh,  Single  hop  connectivity 

Low  cost  unit 

Carrier  Rate:  2.5  Mbps 

Small  Antenna  (2.4  m) 

Demand  assigned  switched  services 

Up  to  2 interfaces 

Concurrent  Voice/Video/Packet  Services 

Optional  Redundancy 

Global  and  Spotbeam  operation 

Gateway  Terminals 

Ku  and  C Band  Operation 

Up  to  32  interfaces 

Compact,  low-cost  hardware 

Full  redundancy 

Support  for  1000's  of  terminals 

Uses  “stack”  of  small  terminal  units 

Intermediate  Size  Terminals 

Fault  Tolerance 

2 to  32  Interfaces  in  increments  of  2 

Redundant  terminal  option 

Field  Upgradeable 

Backup  Reference  Stations 

Optional  Redundancy 

m COMSAT  ATM  Via  Satellite:  Link  and  Networking  Technologies 

LABORATORIES 

Linkway  2000  Bandwidth  Management  Features 

Dynamic,  Real-Time,  Bandwidth  on  Demand 
Bandwidth  Management  done  centrally  by  NCC 

NCC  is  a Sun  workstation,  connected  to  the  Reference  Terminal 
Handles  SVCs  and  PVCs 

Handles  ATM  classes  of  services  • UBR,  VBR,  CBR  (ABR  future) 

Adaptive  bandwidth  allocation  for  UBR  ATM  circuits  and  for  frame  relay 
Based  on  actual  traffic  measurements  and  network  state 
Fairness  algorithms 

Traffic  Policing 

Traffic  aggregation 

Multi-carrier,  TDMA  bandwidth  management  Algorithm 
Variable  sized  bursts 

Modem  pooling  for  multi-modem  terminals 
Fast  execution  algorithms 


13 


(B)  COMSAT 

LABORATORIES 


ATM  Via  Satellite:  Link  and  Networking  Technologies 


Linkway  2000  Key  Technical  Challenges 


TDMA  Architecture  to  support  multiple 
services  with  BoD 
Modulation/Coding/Interleaving 
Adaptive  Modulation/Coding 
Acquisition  and  Synchronization 
Stable  Clock  Generation  using  low  cost 
oscillators 

Frequency  Offset  Management 
Doppler  Management 
Power  Control 

Adaptation  of  Different  Protocols 
ATM,  Frame  Relay,  ISDN,  (IP) 
Guaranteed  GOS,  Priorities 
ATM  Cell  Delay  Variation  Control 
Inverse  muxing 

Bandwidth  Management  Algorithms 
Congestion  Control  Algorithms 
Standards,  Inter-operability 
Network  Management 
Redundancy 

Software  Architecture  - size,  cost,  complexity 
Hardware  - size,  cost,  complexity,  modularity 


On-Going  R&D 
ATM  Multicast 
IP  over  ATM 
IP  Multicast 
Addressing/Routing 
Direct  IP/RSVP  support 
TCP  Performance  Issues 
Security 
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Ka  Band  Operation 


Network  Capabilities 

COMSAT  responding  to  NASA  RFQ  for  TDMA/FDMA  Network  System 
Will  initially  supply  4 units  with  ATM,  FR  and  ISDN  interfaces 

Additional  features  for  operation  over  ACTS : 

- Lower  carrier  rate  option  (O.S  to  1 Mbps) 

- Asymmetric  rate  option  (2.5  Mbps->,  0.5  Mbps  <•) 

- Support  for  On-Board  Microwave  Switch  Matrix 

TDMA  synchronization 
Dynamic  Bandwidth  Management 

Linkway  modem  has  been  tested  over  ACTS  satellite  using  USAT 
terminal 
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Conclusions 


New  generation  of  satellite  link  and  networking 
products  - 

Provide  High  Quality  ATM  Service  over  satellite 
links 

Provide  Efficient  use  of  satellite  bandwidth 
Meet  Customer  Demands 
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Satellite  ATM  Networks:  Architectural  Issues  and 
Challenges 


Sastri  Kota 

Lockheed  Martin  Telecommunications 


In  this  paper  we  present  an  overview  of  the  Ka-Band  satellite  systems  and  broadband  services  and 
applications  which  drive  the  broadband  network  architectures.  We  describe  a Satellite  ATM  Network 
model  and  discuss  various  architectural  options  including  on-board  versus  ground  switching  and 
processing,  and  GSO  versus  NGSO.  For  an  Integrated  Satellite  ATM  network  model  design  issues  such 
as  traffic  management,  quality-  of  -Service  (QoS)  and  media  access  protocols  are  discussed.  The  current 
standard  development  activities  for  satellite  networks  is  presented.  We  then  Illustrate  structure  of  the 
TCP  protocol  stack,  as  an  example  of  a popular  end  system  protocol,  over  the  ATM  Unspecified  Bit  Rate 
(UBR)  category.  We  present  simulation  results  for  end  -tomnd  delay  performance  of  GEO  and  LEO 
systems  for  a sample  connection  from  New  York  to  Paris  and  concluded  that  while  GEO  systems  have  a 
large  propagation  delay,  buffering  delay  can  be  significant  in  LEO  networks. 

Subsequently,  we  present  an  overview  of  Lockheed  Martin's  Astrolink  System  as  a Satellite  ATM 
network  example.  Astrolink  system  is  currently  under  active  development  Astrolink  will  provide  global 
bandwidth  -on  - demand  utilizing  a constellation  of  nine  Ka-Band  geosynchronous  satellites  deployed  in 
five  orbital  locations.  The  Astrolink  will  employ  intersatellite  links,  high  gain  spot  beams,  adaptive 
coding  in  response  to  rain,  and  on-board  ATM  switching.  Astrolink  will  enable  global  broadband 
communication  services  at  an  affordable  price. 


Lockheed  Martin  Telecommunications 

Copyright  61990  Uockhaed  Martin  Corporation 


443 


Outline 


Broadband  services 
Broadband  applications 
Satellite  ATM  network  architectures 
Satellite  ATM  - issues  and  challenges 
Astrolink ™ 

Conclusion 


Lockheed  Martin  Telecommunications 
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Broadband  Services  and  Applications 

What  Interactive  Broadband  Services  do  Users  Want?  - an  Asia  Pacific  Survey* 

- Size  Asia-Pacific  market  potential  for  select  interactive  services: 


Entertainment 


Transactions 

Teleshopping 
Home  Banking 


Data  / Communications 

Internet  Access 


Electronic  Messaging 


Videoconferencing  Electronic  Commerce  News  on  Demand 


Virtual  CD-ROM 
Distance  Learning 


Broadcasting  (DTH)  'Telework  Teleshopping  Internet  Access 

Video  on  Demand  (VOD)  Telemedicine  Home  Banking  Electronic  Messaging 

NearVOD  Video  Conferencing  Electronic  Commerce  News  on  Demand 

TV  Co-Transmissions  interactive  Ads  Virtual  CD-ROM 

Karaoke  on  Demand  Home  Security  Distance  Learning 

Games  Utility  Monitoring 

Gambling 

- Gauge  consumer  acceptance  in  15  Asia-Pacific  countries  at  4 price  points 
(10  to  70  $USD  per  mo)  over  short  term  (3  yrs)  and  long  term  (7-10  yrs) 

- Conclusions  - Top  Tier  of  Desired  Applications 


Interactive  Ads 
Home  Security 
Utility  Monitoring 


Government  and  cultural  support;  business  case  (TBD) 

Internet  Access 


nr,  business  and  consumers 


Electronic  Messaging 


Video  Conferencing 

Strong  business  demand;  several  servicas  currently  offered 
Home  Banking 

Strong  business'  demand;  several  servicas  currently  offered 
Telemedicine 

Sov  support  of  central  hospitals  to  serve  dispersed  communities 


PTH  Broadcasting 

Pent-up  demand  for  'multichannel  TV,  minimal  cable  TV  infrastructure 


* Conducted  during  the  period  Jan  to  Mar  1997 

Lockheed  Martin  Telecommunications 
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Interoperability  Requirements 


1 to  5 5 to  10  10to15  15  to  25  25  to  35  35  to  55  55  to  65 

Countries  with  population  range  (Millions)  able  to  soend  25  $USD  per  month 


Lockheed  Martin  Telecommunications 
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Broadband  System  Applications 


(Content 
Acquisition 


Content 

Development 


Assessments 
System  Meeds 
Problem  statement 
"Best”  solution 
Planning 
Implementation 
Operation 

Improvement 


Terrestrial  I 
Channels  | 


IWfXWM,  dWiWH 

mi 


Interactive  Backchannel 


User  Feedback  Mechanism 


Lockheed  Martin  Telecommunications 
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Satellite  Integration  Lab 


Provides  the  ability  and  expertise  to  rapidly  simulate  satellite  network 
architectures  and  interfaces,  to  integrate  and  test  terrestrial  and  satellite 
optimized  applications  in  both  simulated  and  real  end-to-end  satellite 
networks,  and  to  research  and  compensate  GEO  satellite  effects  on  data 
communication  protocols  f ' 


e Interface  and  emulate  satellite  and  hybrid  terrestrial/satellite  networks 
including  GEO  latency  and  random  and  burst-type  bit  errors 
e interface  Ethernet,  ATM,  and  telephony  over  satellite 
e Set  up  live  satellite  links  using  commerciaf  Ku-,  Ka-band  transponders 
e Send  video  and  data  over  live  satellite  links 
e Set  up  satellite  video  conferencing. 

e Integrate,  test,  and  analyze  performance  of  various  network  protocols 
and  applications  over  emulated  and  real  satellite  links 
e Test  performance  of  satellite  and  hybrid  networks  under  traffic  loading 
e Development  of  TCP/IP  and  TCP/1P-ATM  satellite  g *teways 


Lockheed  Martin  Telecommunications 
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Ka-Band  Satellite  Systems 


High  data  rate  services 

- More  bandwidth  available  - 1 GHz  set  aside  for  GSO  primary  use  in  U.S.,  2.5 
GHz  available  worldwide 

High  capacity 

- Multiple  beam  antenna  technology  and  dual  polarization 
Efficient  routing 

- Onboard  processing  and  switching  provide  ability  to  route  calls  efficiently 
Dynamic  resource  allocation 

- Satellite  capacity  can  be  allocated  to  the  region  depending  on  peak  demands 
Small  terminals 

- Allows  smaller  but  higher  gain  antennas 
14  frequency  filings;  some  of  them  are; 

- Astrolink™  (Lockheed  Martin) 

- Cyberstar  (Loral) 

- GE*  Star  (GE  American  Comm) 

- M-Star  (Motorola) 

- Spaceway  (Hughes) 

- Teledesic  (Teledesic) 

Lockheed  Martin  Telecommunications 
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Satellite  ATM  Network  Mode! 


0*f- 


Inter-Satalllte  Link 


A 


Satellite  ATM 
Interface 


Space 

Segment 


Satellite  ATM  I 
Interface  ZL. 


Network  Control  Center  - — j " 

• Performance  management  (aJU  Switch/ 

• Configuration  management  S-  j 

■ Resource  planning  \ 

■ Billing  ' — \ ' Ground 

T Bridge  ^Segment 


Wlreleaa 

LAN 


Saatfi  Kota,  R.  Ooyil,  and  Raj  Jain,  "SataWta  ATM  Natworfc  ArchKactural  ConaldaratkHi  and  TCP/IP  P ormance” 
Proc.  Third  Ka-Band  Utilization  Contra  net.  Saptambor  11-11, 1117,  Somnto,  Italy 
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Architectural  Options  and  Issues 


Options 

• GSO  vs  NGSO  (e.g.,  LEOs,  MEOs) 

• No  onboard  processing  or  switching 

• Onboard  processing  with  ground  ATM  switching 

• Onboard  processing  and  ATM  switching 

• Applications 

• Services 

Issues 

• Media  access  control  protocol 

• Traffic  management 

• Interoperability  with  legacy  networks 

• QoS  management 


Lockheed  Martin  Telecommunications 
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Satellite  ATM  Versus 
Terrestrial  ATM 


Attributes 

•Encoding  for 
error  performing 

•Signaling 

•DAM  A 

•Traffic 

management 

•User  protocol 
interface 

•Switching 

• Propagation 
delays 

•Standards 


Terrestrial  ATM 
HEC  only 

Standards  Q.2931 
No 

Standard  ATMF  V.4.0 

UNI,  NNI,  etc. 
standards 

VP  and  VPI/VCI 

Less  impact,  but  number 
of  hops  during  the  path 

Have  progressed  well 


Satellite  ATM 
Link  encoding  powerful 

Requires  modifications 

For  efficient  resource 
utilization 

Requires  modifications 

ST  and  Gateway 
implementation 

VPI/VCI 

IETF  developing  efficient 
algorithms  (IPOS) 

ITU  4B  draft 
Due  October  98 


Lockheed  Martin  Telecommunications 
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Onboard  Processing  and  Switching 


1 Improved  performance  for  error  rates 

- Separation  of  uplink  and  downlink 

- Effective  encoding  techniques 
1 System  efficiency 

- Efficiency  can  improve  from  37%  to  nearly  99.5%  with  packet 
or  cell  switching 

• Delay  improvements 

- Routing  decisions  onboard  or  via  intersatellite  links 

- No  end-to-end  retransmissions 

• Capacity  improvements 

- Multiple  beams  with  dual  polarization 

“70%  of  the  Ka-band  programs  forsee  an  onboard  switch,  53%  use  fast 
packet  switch”  - Proc.  Third  Ka-band  utilization  conference,  pp.  281-285 
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TCP/IP  Over  Satellite  ATM  Example 


Application 

TCP/UDP 

IP 

AAL 

Switch 

ATM 

ATM 

SONET 

SONET 

Physical 

Physical 

i 

MAC 

Phy 

IphyJ 

£ 

£ 

ATM 

MAC 

SONET 

Phy 

Phy 

Physical 

Host 

Application 

TCP/UDP 

JP 

AAL 

ATM 

SONET 


How  does  the  TCP/IP  protocol  stack  work  with  satellite  ATM? 
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Satellite  ATM  Services  Classes 

• CBR  (constant  bit  rate) 

- User  declares  required  rate.  Throughput,  delay,  and  delay 
variation  guaranteed.  Circuit  emulation 

• VBR  (variable  bit  rate) 

- Declare  average  and  maximum  rate 

• rt-VBR  (real  time):  Conferencing.  Max  delay  guaranteed 

• nrt-VBR  (non-real  time):  Stored  video 

• ABR  (available  bit  rate) 

- Source  follows  network  feedback 

• UBR  (unspecified  bit  rate) 

- User  sends  whenever  it  wants.  No  feedback.  No  guarantee. 
Cells  may  be  dropped  during  congestion 


Fiexibili 
needs  v 


Most  important  benefit 

ibility  of  ATM  to  allocate  resources  appropriate  to  each  application’s 
ds  while  allowing  sharing  where  possible  to  lower  networking  costs 
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Traffic  Management  Functions 


• Connection  Admission  Control  (CAC):  Verify  that  the  requested 
bandwidth  and  quality  of  service  (QoS)  can  be  supported 

• Traffic  shaping:  Limit  burst  length.  Space-out  cells 

• Usage  Parameter  Control  (UPC):  Monitor  and  control  traffic  at  the 
network  entrance 

• Network  resource  management  Scheduling,  queuing,  resource 
reservation 

• Priority  control:  Cell  Loss  Priority  (CLP) 

• Selective  cell  discarding:  Frame  discard 

• Feedback  controls:  Network  tells  the  source  to  increase  or  decrease 
its  load 


Traffic  management  version  4.0,  requires 
modifications  to  reflect  Satellife  ATM 

Lockheed  Martin  Telecommunications 
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Satellite  ATM  Attributes  on  QoS 


Attribute 

Propagation  delay  on 
transmission  media 
Error  characteristics 
of  transmission  media 
Switch  architecture 
Processor  and  buffer 
capacity 


Max  CTD  Peak-to-Peak  CDV  CLR  CMR  SECBR  CER 


Maximum  nodes 
allowed  in  a route 
Resource  allocation 
strategy 

Network  failure  and 
restoration  strategy 


CLR:  Cell  loss  ratio 

CTD:  Cell  transfer  daisy 

CDV:  Peak-to-peak  call  delay  variation 


CMR:  Cell  misinsertion  rate 
SECBR:  Severely  erred  ceil  block  ratio 
CER:  Call  error  ratio 


S.  ATM  attributes  consistent  with  terrestrial  ATM 

Lockheed  Martin  Telecommunications 
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TCP  Issues 

• Basic  TCP:  Slow  start  and  congestion 
avoidance 

- Large  retransmission  timer  granularity 
c=>  slow  recovery  from  packet  loss 

• Reno  TCP:  Fast  retransmit  and  recovery 

- Fast  recovery  from  single  packet  loss 

- Very  inefficient  with  multiple  packet  loss 

• SACK  TCP:  Selective  acknowledgments 

- Fast  recovery  from  multiple  packet  loss 

For  satellite  networks,  SACK  TCP  has  the  best  performance 
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End-to-End  Delay  Peformance 


End-to-End  Delay  = Packet  Transmission  Delay 
+ Propagation  Delay 
+ Buffering  Delay 
+ Switching  and  Processing 


Delay  Variation: 

- Handovers 

- Satellite  Motion 

- Buffering  and 
processing 

- Adaptive  routing 


Source  1 


Source  N 


Switch  Switch  1 


Satellite 

Network 


Destination  1 


Destination  N 
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New  York  to  Paris:  Delay  Analysis* 


Delay 

GEO  (ms) 
1 Satellite 

6x11  (ms) 
5 Satellites 

12x24  (ms) 
10  Satellites 

Transmission 

Negligible 

Negligible 

Negligible 

Propagation  (up+down+ISL) 

250 

60 

77 

Switching  and  Processing 

Negligible 

Negligible 

Negligible 

Buffering  (N  queuing  points) 

0 to  N*250 

0 to  N*60 

0 to  N*77 

Total  Delay 

250  to  500 

60  to  420 

77  to  924 

Simulation  results  indicate  that  a buffer  size  of  about  0.5  RTT  to  1 RTT  is 
sufficient  to  provide  over  98%  throughput  to  the  SACK  TCP  traffic  for  long 
latency  networks  and  a larger  number  of  sources** 

* R.  Ooyal,  8.  Kota  and  R.  Jain  at  al.,  “Analysts  and  aimuMon  of  dal  ay  and  buffsr  refinements  of  Satellite  ATM  networks  tor  TCP/ 

IP  traffic  summltod  to  IEEE  journal  of  saiactad  araas  In  communication 
**  S.  Kota,  R.  Ooyal,  and  R.  Jain,  “8  stall  It*  ATM  Network  Architectural  Consider  •♦tone  and  TCP/IP"  performance,  Third  Ka-band 
utilization  conference,  Sorrento,  Italy,  September  1997,  pp.  491-488 
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Satellite  ATM:  Standards  Activities 


• ITU-R  WP  4B  - Developed  draft  new  recommendation  on  S.  A TM 
and  S.  ATM  availability  (to  be  approved  by  October  1998) 

• ITU-R  WP  4B  - Initiated  draft  new  recommendation  on  Ka-band 
performance,  March  1998 

• TIA/EIA  released  “Satellite  ATM  Networks:  Architectures  and 
Guidelines" 

• ATM  forum:  Wireless  ATM  Working  Group  initiated  a Mobile 
Switching  Subworking  Group  in  ATM  forum  meeting,  April  19-24, 
1998,  Berlin 

• IETF:  Internet  protocol  over  satellite  (IPOS)  has  released  a draft 
specification 


A good  coordination  requires  to  be  established  via  liaison 
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Astrolink™  is 


a Global  Satellite  Network 


Employing 

• Up  to  9 GSO  satellites 

• Satellite  onboard  processing 

• Ka-band  ( 20/30  GHz)  frequencies 

• 3 Classes  of  user  terminals 

• Gateway  earth  stations 

• Intersatellite  links 


Based  On 
I • ATM  Protocol 


Providing 

- Interactive  2-way  services  - data,  voice,  video 
.and  multimedia 

• Bandwidth-on-demand  - IS  kbps  to  10.4 
Mbps 

• Quality  of  service  options  tailored  to 
applications 

• Secure  private  virtual  circuits 

• Interoperability  with  terrestrial  networks 

• Connectivity  to  and  from  external  users  via 
gateways 
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Astrolink™  Services 


k £ 

IlglB  Mod  lea  I 


Tala  phony 
TOcefTtol) 

Fax 

Email 

EFT  (1  to  1) 
Symmetric  traffic, 
.low  data  rata  j 


Travel  and 
Transportation 


Software 

Distribution 


Collaborative  Working 
Desktop  Videoconferencing 
Room  Videoconferencing 
Telemedicine 
CAD/CAM  Work 
Distance  Learning 
Symmetric  traffic, 

.video  and  data  intensive  _ 


/Virtual  Private  Networks  - 


LANtoLAN 
Internet  Access 
Intranet 
Games 

ECommercs/EDI 

Multicast 

Trunked  Telephony 
Symmetric  traffic,  data 
V Intensive 


Large  File  Transfers 

Video  blips  <l6  min. 

Image  Transfer 
Video  Transfer 
Electronic  Product  Distrib. 
(s/w,  video,  music,  books) 
Asymmetric  traffic, 
.Image  Intensive . 


Astrolink™  will  provide  wideband  global 
connectivity  for  enterprise  applications 

Lockheed  Martin  Telecommunications 
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Astrolink™  Satellite 
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Copyright  Cl  998  locfchMd  Martin  Corporation 


455 


456 


>ei 


* Master  Network  Control  Center 

• Regional  Network  Control  Center  (NCC) 

-Performs  overall  network 

- Manages  and  allocates  satellite  resources 

resource  management 

as  required 

-Collects  usage  statistics 

- Controls  all  satellite  payload  operations 

-Operates  as  clearing  house 

- Controls  all  traffic  within  a given  satellite 

between  regional  NCCs 

-Validates  users 

- Provides  call  setup  and  tear-down,  data 
rate,  frequency,  and  time  slot  (DAMA) 
assignments 

-Collects  billing  information 

- Provides  billing  and  system  utilization 
data  to  local  ASP  and  Master  Network 
Control  Center 

Spacecraft  Operations  Canter 

- Performs  satellite  housekeeping 
functions 

• Attitude  control,  thermal  and 
power  management 

• Monitors  and  evaluates 
spacecraft  health 

- Plans  and  executes 
stationkeeping  maneuvers 

- Plans  for  contingencies 

• Implements  backup 
redundancy  recovery 
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Conclusions 


Satellite  ATM  architectural  options  exist  in  terms  of  onboard 
processing  and  switching 

Trade-off  analyses  for  performance,  complexity,  and  cost  dictate 

the  selection  of  the  system  architecture 

Standards  organizations  are  progressing  well  with 

recommendations  and  baseline  documents 

Astrolink ™ is  an  example  of  such  a satellite  ATM  network  for 

broadband  services 
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FPGA  Based  Reconfigurable 
ATM  Switch  Test  Bed 


Pong  P.  Chu 

Electrical  and  Computer  Engineering  Dept 
Cleveland  State  University 

Robert  E.  Jones 
NASA  Lewis  Research  Center 


Network  Performance  Evaluation 

♦ Seeking  optimal  configuration 

♦ Difficult  in  general: 

- performance  effected  by  switch  architecture, 
network  topology,  protocols,  incoming  traffic 
patterns  etc. 

- system  characterized  by  many  stochastic 
processes 
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Traditional  Approach 

♦ Theoretical  model  with  closed-form  solution 

- extremely  simple  model;  e.g.,  M/M/1  queue 

♦ Theoretical  model  without  closed-form  solution 

- with  an  analytical  procedure  to  obtain  solution 

- more  realistic,  but  still  with  lots  of  assumptions  and 
approximations 

♦ Prototyping  physical  system 

- expensive,  inflexible 

- technology  may  not  exist  yet 


♦ Software  simulation 

- can  model  at  any  level  of  abstraction 

- require  several  orders  of  magnitude  of  CPU  clocks  to 
simulate  1 real-time  clock 

- e.g.,  experience  from  an  earlier  ATM  switch  project 

» it  takes  0.1  to  1 m sec  to  simulate  the  operation  of  one  cell 
(using  BoNES  Designer  Software  in  Sun  Sparc  II) 

» it  will  require  more  than  100  days  to  measure  a buffer  with 
a cell  loss  probability  of  10'7 
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♦ Use  hardware  to  accelerate  simulation 

♦ Construct  customized  circuit  to  model  various 
network  components 

♦ Recent  advances  in  FPGA  (Field  Programmable 
Gate  Array)  technology  make  this  possible 

- FPGA:  “generic  logic”  that  can  be  configured  to 
different  functions  by  loading  different  files 

- a chip  can  accommodate  circuit  with  100,000  gates 

- synthesis  CAD  software  simplifies  implementation 


Test  Bed  Highlights 

♦ Model  the  operation  of  an  ATM-like  switch 
based  network  in  an  FPGA  board 

♦ Model  data-link  level  functionality  (such  as 
buffer  management,  congestion  control  etc.) 

♦ Use  a host  PC  to  control  and  monitor  the 
operation  of  the  FPGA  board 

♦ Most  design,  synthesis,  and  simulation  are 
based  on  industrial  standard  VHDL  language 

♦ Design  goal:  modular,  scalable,  reconfigurable 
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♦ Model  after  a shared-memory  ATM  switch 

♦ Process  only  the  cell  header 

♦ Perform  only  data-link  level  functionality 

♦ Include  control  circuit,  FIFO  buffer  and  status 
circuit. 

♦ Incorporate  three  buffer  management  schemes: 
complete  sharing,  complete  partition,  and 
sharing  with  maximal  queue  length 


Detailed  Switch  Diagram 


« | Data  Memory  Uu^g 
i — * Counter  i 


Read-Out  Cot 

Sums  Checking  Count., 


Control  Signal 
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♦ Cell  format: 

- header  only  (destination  port  etc.) 

♦ Traffic  generator 

- Cell  trigger  generator 

» deterministic  arrival 
» Poisson  arrival 

» Markov  modulated  Poisson  arrival 

- Cell  destination  port  generator 

» uniformly  distributed 
» unbalanced 


Data  Collection  Circuit  and 
User  Interface 


♦ Data  collection  circuit 

- gather  statistics  on  total  cell  arrival,  cell  loss  due  to 
global  buffer  overflow,  and  cell  loss  due  to  FIFO 
overflow 

♦ User  interface 

- Hardware:  PC  ISA  bus  interface  in  FPGA  board;  all 
registers  of  test  bed  can  be  accesses  as  PC’s  memory 

- Software:  C routines  to  download  configuration  file 
to  the  FPGA  board,  to  set  up  the  test  bed,  to  monitor 
the  board  operation  and  to  retrieve  collected  data 
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Initial  Results 


♦ Test  bed  was  designed  to  study  cell  loss  probability 
of  various  memory  management  schemes 

♦ It  was  fitted  into  one  100,000-gate  FPGA  board 

♦ Performance 

- max  clock  about  15  MHz 

- can  emulate  about  3 M cell  arrivals  per  sec 
(1.2  G bits  per  sec) 

- 5.5  min  to  emulate  109  cell  arrivals 

♦ Emulation  increases  speed  by  a factor  of  103  to  105 


Example:  System  Load  vs  Cell  Loss  Probability 
w/  Different  Buffer  Sizes  in  an  8x8  Switch 
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Conclusions 


♦ Advances  in  FPGA  make  hardware  emulation 
feasible  for  performance  evaluation 

♦ Hardware  emulation  can  provide  several  orders 
of  magnitude  speed-up  over  software 
simulation 

♦ Due  to  the  complexity  of  hardware  synthesis 
process,  development  in  emulation  is  much 
more  difficult  than  simulation  and  requires 
knowledge  in  both  networks  and  digital  design 
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Session  8 

Access  Technology  and  Protocols 
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User 

(TCP) 


User 

(TCP) 


Modem 


Modem 


Integrated  Packet  / Modem 
Processing 

for  Transportable  Terminals 


Gorry  Fairhurst 
Department  of  Engineering 
University  of  Aberdeen 


Who  needs  to  know  th/s? 

G.  Fairhurst 


People  designing  modems 

Mobile  terminals 

Transportable  / rapid  deployed  terminals 
Terminals  suffering  interference 
High  availability  systems 

People  refining  TCP 
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G.  Fairluirst 


Modem  Modem 

TCP,  routers  and  modems  operate  independently 


Observation 

Packet  loss  due  to  link  errors 
significantly  reduces  performance 

TCP  Issues 

Optimised  for  congestion  loss 

Can  be  improved  by 

Modifying  TCP 
Improving  modem 
Link  layer  ARQ 


TCP  Link  Performance 

G.  Fairhurst 


Bit  Error  Rate 

Simulation  results  using  a 64kbps  link 
with  280ms  propagation  delay 
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Solution  1:  FEC 


G.  Fairhursl 


May  achieve  any  BER 

Need  to  identify  worst  case  Eb/No 
Issues 
Overhead 
Outages 


How  Much  FEC? 


G.  Fairhurst 


Use  as  much  FEC  as  you  like 
- but  still  pay  for  it  when  you  don’t  need  it. 

For  99.9%  of  time  little  may  be  needed 


471 


Throughput  Efficiency 


G.  Fairhurst 


Link  ARQ  may  provide  reliability 
Issues 

Packet  overhead 
Variable  delay 
Utilisation 


HDLCJJnkARQ 

G.  Fairhurst 


Protocol 


REJ 

BREJ 

SREJ 

MREJ 

MSREJ 

BREJ+PCR 

SREJ+PCR 

MREJ+PCR 

MSREJ+PCR 


Large  selection  of  known  ARQ  techniques 
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G.  Fairhursl 


Observation 

Performance  not  much  improved 

Strict  reliability  guarantees 

No  loss  (i.e.  error  recovery) 

No  duplication 
Sequence  delivery 


Bit  Error  Rate 

Simulation  results  using  a 64kbps  link 
with  280ms  propagation  delay 


Issue 

Delay  due  to  link  protocol  sequencing  and  recovery 


Sequencing  and  Recovery  Delay 

G.  Fairhursl 


Packets  from  different  applications 


Receiver 

sequencing  buffer 
Delay  due  to  error  recovery 
Delay  due  to  sequencing 


Interaction  between  different  applications 
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TCP  /Link  Interaction 

G.  Fairhurst 


TCP  retransmits  packet  one 


Forwards  all  buffered  TCP  packets 
after  recovery  of  packet  1 


End-to-end  (e.g.  TCP)  and  link  (e.g.  HDLC)  error  recovery  interac 


TCP  doesn’t  need  strict  reliability 

Needs  timely  delivery 

Efficient  error  recovery  (RDLP) 

Limit  number  of 
retransmission  requests 

Provides  out  of  order  delivery 

Segmentation  (RDLA) 

Transparent  segmentation 


A Robust  Data  Link 

G.  Fairtiursl 


too- 

80  - 

60  - 

\ \\ 

40  “ 

\ \\ 

*— 

a TCP/RDLP  \ \\ 

20  “ 

dTCP/RDLP/RDLA\  \ 

* Theoretical  Maximum^  ' 

U 1 

0-7  10-6  lb-5  io-4  lo 

Bit  Error  Rate 

Simulation  results  using  a 64kbps  link 
with  280ms  propagation  delay 
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G.  Fairhursl 


Options 

Modulator  may  pick  from  range  of  options  (Eb/No) 
Demodulator  knows  much  about  channel  state 
There  is  a great  deal  of  synchonisation 


Adaptive  FEC:  Smart  Codec 


Adaptive  Coding 
(Simple  Waveform 
wjth  Enhanced  Protocols) 

Enhanced  Protocols, 
v Standard  Waveform 

\ / Sophisticated 

iii,x  x Waveform 


G.  Fairhurst 


10^5 10-4 Iq-3 10-2 

9.6  dB  8.7  6.7  4.1  Eb/No  (dB) 

May  adapt  modem  waveform  to  channel  state 

For  99%  time  the  channel  may  be  benign 

issues 

Channel  state  estimation 

Best  effort  service  (also  needs  FEC/ARQ) 

Capacity  of  link  varies 
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SATCOM 


Adaptive  FEC 

G.  Fairhurst 


Time  ( s ) 


Tl  1000  2000  30003500 


Typical  Rain  Fade  ~ 

0 

g 0.7 

1 06 

S 0.5 


fixed  1/2  rate  codec 
uncoded  channel 


Smart  Codec 


I 0.4 
o>  0.3 
o 0.2 
i—  0.1 
0 


Adaptive  FEC: 

Improves  clear  sky  performance 
Varies  path  capacity 
Accepts  some  loss 


Link  Throughput 


.Smart  Codec 
selects  uncoded  j 
-channel  (bypass)  1 

Smart  codec 
/selects 
' 3/4  rate  code 

Performance  of 
standard  1/2 
codec 

\ '''smart 
l Codec  , 

\ selects  / 

\ 1/2 

\ coded  1 
^channel  ( 

Smart  ' 

Codec 

tracks 

upward 

movement 

of  channel 

state 

JgtSSM 

\ 

0 500  1000  1500  2000  2500  3000  3500 


time  (s) 


Where  Next? 

G.  Fairhurst 

Link  Adaption  (with  partial  reliability) 

Modulation 

FEC 

ARQ 

Link  Indication  to  TCP 

Explicit  loss 

Path  change  indication 

Congestion  indication 

TCP  Modifications 

SACK 

RTO  calculation 
Loss  differentiation 
Start-up  behaviour 
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Conclusions 


G.  Fairtiurst 

Satellite  links  may  be  made  error-free 

FEC 

Strict  Reliability 

Outages  may  still  be  possible 

Performance  tradeoffs  exist  at  various  layers 

Link  must  complement  TCP  behaviour 

TCP  doesn’t  need  strict  reliability 
Delay  variation  should  be  limited 
Interaction  between  applications  minimised 

It  would  be  nice  if  TCP  were  smarter :-) 
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Multiple  Priority  Distributed  Round  Robin 
Introduction 

♦ ATM  Processing  Satellite  Description 

♦ Traffic  Types 

♦ Satellite  ATM  MAC  Challenges 

♦ Proposed  MAC  Protocols  for  Satellite  ATM 

♦ MPDRR  Description 

♦ MPDRR  OPNET™  Simulation  Results 
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♦ Multiple  Spot  Beams 

♦ Digital  On  Board 
Processing 

♦ On  Board  Fast  Packet 
Switch 

♦ MF-TDMA  Uplinks,  TDM 
Downlinks 

♦ Many  Terminals  Sharing 
the  Uplink  Bandwidth 
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Multiple  Priority  Distributed  Round  Robin 
Examples  of  Services 

♦ Voice 

♦ Video 

♦ LAN  Interconnection 

♦ Telemedicine 

♦ Internet  Access 

♦ Telecommuting 
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♦ Constant  Bit  Rate  (CBR) 

♦ Variable  Bit  Rate  - real  time  (VBR-rt) 

♦ Variable  Bit  Rate  - non  real  time  (VBR-nrt) 

♦ Available  Bit  Rate  (ABR) 

- Higher  Priority  for  Minimum  Ceil  Rate  (MCR) 

♦ Unspecified  Bit  Rate  (UBR) 

- Higher  Priority  for  UBR+  Guaranteed  Rate 

♦ ATM  Signaling 
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Multiple  Priority  Distributed  Round  Robin 
Satellite  ATM  MAC  Protocol  Challenqes 


♦ Satellite  Terminals  Need  to 
Share  Uplink  Bandwidth 

♦ Bursty  Data  Traffic  Requires 
Flexible  Bandwidth  Allocation 
(Bandwidth-on-Demand) 

♦ Random  Access  Protocols 
Perform  Poorly  During  High 
Utilization  and  Cannot  Provide 
QoS  Guarantees 

♦ MF-TDMA  Uplinks  Increase 
MAC  complexity  compared  to 
TDMA 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 
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Satellite  ATM  MAC  Protocol  Challenges  fcont 


♦ MF-TDMA  Frame  Structure 

♦ Terminals  Can  Only  Transmit 
on  One  Frequency  at  a time, 
i.e.,  Slot  Assignments  Must  Not 
Overlap  in  Time 

4 Each  Terminal  Can  Be 
Assigned  Up  to  N Slots 


FREQUENCIES 

n o f4 
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Multiple  Priority  Distributed  Round  Robin  / 
Satellite  ATM  MAC  Protocol  Challenaes  (cont.)  Cj 


4 Satellite  Mass  and  Power 
Restrictions  Limit  On-Board 
Complexity 

4 Terminals  Complexity  is 
Limited  by  Cost  Constraints 
4 The  Propagation  Delay  of 
Geostationary  Satellites 
Impacts  MAC  Performance 
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Proposed  ATM  Satellite  MAC  Protocols 

♦ Protocols 

- CFDAMA1 

- Distributed  Access  Protocol2 

- Hierarchical  Round  Robin3 

- Round  Robin  Reservation  DAMA4 

♦ Areas  for  Improvement 

- Most  Protocols  Designed  for  TDMA  Uplinks 

- MF-TDMA  Slot  Assignments  Not  Addressed  in  the  Literature 

- Only  Round  Robin  Reservation  Designed  for  Distributed  Control 

[1]  J.  I.  Mohammed,  T.  Le-Ngoc,  “Performance  Analysis  of  Combined  Free/Demand  Assignment  Multiple  Access  (CFDAMA)  Protocol  for 
Packet  Satellite  Communications,”  ICCC  ’94,  pp.  869-873 

[2]  F.  D.  Priscoli,  M.  Listanti,  A.  Roveri,  A.  Vemucci,  “A  Distributed  Access  Protocol  for  an  ATM  User-Oriented  Satellite  System,” 
Proceedings  of  the  ICC  ‘89,  June  1 989,  paper  22. 1 . 

[3]  A.  Hung,  M.-J.  Montpetit,  G.  Kesidis,  “ATM  via  Satellite:  A Framework  and  Implementation,”  Wireless  Networks,  Vol.  IV,  No.  2, 1998 

[4]  S.  L.  Kota,  J.  D.  Kallaus,  “Reservation  Access  Protocol  for  Multiplanar  ATM  Switched  satellite  Network  (MASSNet)  ” KULCOM  '94 
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Multiple  Priority  Distributed  Round  Robin 

MPDRR  Overview  ^ 


♦ Multiple  Priority  Distributed  Round  Robin  (MPDRR) 
Protocol  Developed 

♦ Designed  for  (But  Not  Limited  To)  Use  in  ATM  Over 
Geostationary  Satellites  With  MF-TDMA  Uplinks 

♦ Designed  for  Distributed  Control,  but  Will  Also 
Work  With  Centralized  Control 

♦ OPNET  Model  Built  for  MPDRR  Simulation 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 
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Overlap 

♦ No  Wasted  Slots  Because  All  Slots  Re-assigned  Every 
Superframe 

♦ Simplicity  Enables  Distributed  Control 

♦ Terminals  Must  Change  Frequencies  Within  a Frame 


T1  j T1  T1  T1  j T1  j T1  T1  T1  I T2  T2 


T2  T2  T2  T2  T2  T2  T3  73  T3  T3 


T3  T3  T3  T3  T4  T4  T4  T4  T4  T4 


T4  T4  T5  T5  T5  T5  T5  I T5  T5  T5 
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Multiple  Priority  Distributed  Round  Robin  / 
MPDRR  Overview  77 


♦ Terminals  Calculate  the  Number  of  Slots  to  Request  for  Each 
Priority 

♦ Terminals  Transmit  Request  Messages  in  Assigned  Overhead 
Slots 

♦ The  Satellite  Receives  Request  Messages  and  Transmits  Them  on 
the  Proper  Downlink 

♦ Terminals  Receive  and  Sort  Request  Message  From  All  Terminals 
in  Their  Group 

♦ Terminals  Calculate  the  Slot  Allocation  for  Each  Terminal,  for 
Each  Level  of  Priority  Using  a Round  Robin  Algorithm 

♦ Terminals  Calculate  the  Slot  Assignment  for  Each  Terminal  (Time 
and  Frequency)  Using  the  Sequential  Assignment  Algorithm 

♦ Terminals  Transmit  on  Their  Assigned  Slots  Starting  With  the 
Next  Superframe 

LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 
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Multiple  Priority  Distributed  Round  Robin  A 
MPDRR  OPNET  Preliminary  Simulation  Results  Cn 

♦ One,  Two,  Four  and  Eight  384  kbps  Uplink  Channels 

♦ Markov  Modulated  Poisson  Process  (MMPP)  Used  as 
Bursty  Traffic  Sources 

- Peak  Bit  Rate  = 128  kbps 

- Mean  Burst  Length  = 16250  bytes 

- Activity  Factor  = 0.1 

♦ Uplink  Delays  Only  on  Charts 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 


Multiple  Priority  Distributed  Round  Robin  / 
Extra  Slots  Allocated  Fairly  to  all  Terminals 


. 1 channel 
. 2 channel 
.4  channel 
. 8 channel 


Utilization 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 
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Utilization 


1 Terminals  with  pending  slot  requests 


. 1 channel 
. 2 channel 
.4  channel 
. 8 channel 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 


Multiple  Priority  Distributed  Round  Robin 
Conclusions 


♦ ATM  Processing  Satellites  with  MF-TDMA  Uplinks 
Require  a New  MAC  Protocol 

♦ MPDRR  Is  a Candidate  MAC  for  Satellite  ATM 

♦ Preliminary  Simulation  Results  Demonstrate  the 
Benefit  of  Sharing  Uplink  Channels 

♦ Further  Analysis  and  Simulation  Planned 


LOCKHEED  MARTIN  FEDERAL  SYSTEMS  MANASSAS 
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Flow  Control  and  Dynamic  Bandwidth 
Allocation  in  DBS-Based  Internet 


Gabriel  Olariu 

Hughes  Network  Systems 


John  S.  Baras 

Center  for  Satellite  and  Hybrid 
Communication  Networks 
University  Of  Maryland 
College  Park 


Satellite  Networks:  Architectures,  Applications  and  Technologies 
NASA  Lewis  Research  Center 
June  3, 1998 


DBS  - based  Hybrid  Internet  Service 


• Conventional  Internet  access  either  too  slow  or  too 
expensive 

• DirecPC  Turbo  Internet™ 

• conceived  and  designed  by  the  University  of  Maryland 

• productized  and  marketed  by  Hughes  Network  Systems 

• Awards 

• 1994  Outstanding  Invention  of  the  Year,  Univ.  of  Maryland 

• ComNet  ‘96  New  Product  Achievement  Award  (wireless) 

• 1996  “Hot  Product”,  network  services,  Data  Comm.  Magazine 

• 1996  Technical  Excellence  Award  (Net.  Hardware ),  PC  Mgzine 
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Extensions 


• Two  IETF  WGs:  TCP  over  Satellite  and  Unidirectional  routing 

• Intelligent  asymmetric  data  transmission 

• Low  data-rate  (or  “short  length”)  via  terrestrial 

• High  data-rate  (or  “bulky”)  via  satellite 

• Terrestrial  LAN  extension  of  DBS-based  Internet 

• Distribute  DBS  services  from  a single  receiver  to  multiple  users 

• Satellite  hybrid  hosts  can  redistribute  data  to  mobile  users 

• “Local  loop”  anything:  Ethernet,  ATM,  cable  TV,  wireless 

• Reliable  multicast  over  hybrid  networks 

• Hybrid  Internet  service  over  other  hybrid  network  architectures 


Architecture  of  the  Hybrid 
Internet  Service  Network 


FWCaoa  - 
! HGW 


r QM 

IH  N 

j) 

J 

•HH:  Hybrid  Host 

•IH:  Internet  Host 
(Server) 

•ISP:  Internet 
Service  Provider 

•HGW:  Hybrid 
Gateway 

•SGW:  Satellite 
Gateway 

•NOC:  Network 
Operations  Center 
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for  Hybrid  Internet  Service 


• Congestion  control : TCP  and  TCP  Spoofing 

Satellite  channel  bandwidth  allocation 

• HGW  : first  NOC  object  that  receives  data  ( Router) 

- HGW  prioritizes  Hybrid  Internet  traffic 

• SGW  jobs  : mixture  of  Internet  and  exogenous  traffic 

- Exogenous  traffic:  package  delivery  and  data  feed  traffic 

- SGW  maintains  four  queues  : two  for  package  delivery  and  data  feed 

two  for  the  two  priority  levels  of  Internet 

• Exogenous  traffic  high  priority : fluctuations 

in  bandwidth  allocated  to  Hybrid  Internet 

• Self-similar  traffic:  Interactive  users  as  ON-OFF  processes 


DSHGfl 


Flow  Control  Analysis  Model 


(11  Data  connection: 


IS  sends  data  to 
corresponding  HH 


From  HGW  to  IS 


From  HH  to  HGW 

SGW  has  two  queues: 
High  priority 
Low  priority 


SGW  policy:  if  the  number  of  un-acknowledged  bytes  for  a connection  is  less 
than  a configurable,  but  fixed,  threshold  value,  then  these  packets  are 
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Problem: 

• Independent  sources  IS(i),  i=l,2, M,  send  data  to  HHs  via  NOC 

* Find  maximum  M allowed  without  producing  overflow  in  the  NOC 

.®  a® 

k k+i  ' 

...  - - - (0  (0 

0,1  : Pareto , 

fin.  mean,  inf.  variance 

(0 

Arrival  epochs  : CL^ 

Packet  generation  rate 

(/)  _ juIS,  if  IS  busy 
A*  ~ 0,  if  IS  iddle 
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The  Aggregate  Process 
in  the  Limit  of  Many  Sources 


• Average  rate  : E d'u  \ = nIS  — — — 

L -J  Mb+Mi 

• Aggregate  arrival  traffic:  integer  valued  random  point  process 

a(M)={ak(M) \keZ} 

• Marked  point  process  (Mark  = duration  of  busy  period) 

• Likhanov  etal  (1995):  Take  limit  as  M-»oo,  so  that 

X = M /(£[£]  + £[/])  = const.  ’ E[B]=const.  and  E[I] >oo 

- (M ) = No  of  busy  periods  arriving  at  a generic  queue  at  time  k 

- (M)  tends  to  a Poisson  with  rate 

- In  (as,Bs),Bs  is  independent  from  as  and 
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• Each  arrival  has 
service  requirement  Yk 

• Aggregate  traffic 
shares  buffer  space 

• Source  level  analysis 


* For  individual  source  we  have  a G/D/l  queue  (constant  packet  size) 

* Aggregate  traffic  is  Poisson  for  large  M:  So  we  have  a M/G/l  queue 

- Solve  for  the  stationary  state-occupancy  probabilities 

- State  X=\xk\ki  eZ  = No  of  sources  in  the  queue  at  time  k{ 

- Arrival  process  : the  aggregate  process  with  rate  X 

- Service  process,  heavy  tailed,  Pareto;  Stationarity  if  p — XfA  B < 1 


DshcH 


The  Service  Facility  (NOC) 


• Probability  that  / new  sources  will  enter  queue  during  one  busy  period; 
Used  in  network  dimensioning:  An  estimate  for  the  No  of  connections  that 
can  be  busy  during  a typical  ON  period 

• Balance  equations 

qi  = P\Xk=i\  qQ=\— X/j,  B 
1 ^ 

4j+ \=~r  <lj-L  Pi  4j-M-Pj9o 

r0  L 7=1 

• Packet  level  analysis:  loss  probability  in  finite  capacity  queue  (Likhanov) 


I nTliroalrjiiu  3 iWTiWiTTaTa  n 
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Probability  that  a large  number  of 
sources  will  joint  the  queue 
during  a busy  period 
Prob.  of  No  of  sources  in  queue 
decreases  algebraically  fast 


L-l 

100  sources  aggregated. 

Each  source:  1 packet  / simulation  clock 
No  of  sources  in  busy  state  at  any  moment 


NOC: 

Bandwidth  Allocation  Strategies 


• All  strategies:  controller  knows  (per  connection)  queue  status 

• Demand  at  time  t : No  of  packets  in  queue  not  sent  and  unACK, 

and  No  of  packets  that  have  just  arrived 

• Queue  length  used  to  determine  buffer  availability  for  newly  arrived  packets 

• Three  strategies  investigated: 

• Equal  Bandwidth  allocation  (EB) 

• Fair  Bandwidth  allocation  (FB) 

• Most  Delayed  Queue  Served  First  Bandwidth  allocation  (MDQSF) 

• In  EB  demands  may  be  zero  for  many  instants:  waste  of  BW 

• FB  better  for  connection  requests  and  min.  waste  of  BW 

• MDQSF  is  best 
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Equal  Bandwidth  Allocation  (EB) 

• Step  1 : Find  the  number  of  connections  with  non-zero  demand 

• Step  2:  Allocate  the  whole  bandwidth  equally  to  connections  in 
the  set  generated  at  Step  1 

Steps  1, 2 performed  on-line.  Necessitates  large  computing 
resources  for  simulation  and  for  real-world  implementation 
Demands  may  be  zero  for  a large  set  of  clock  instants 
Positive  impact  on  delay,  but  significant  waste  of  bandwidth 


NOC: 

Bandwidth  Allocation  Strategies 


• Fair  Bandwidth  Allocation  (FB) 

• Step  1 : Find  number  of  connections  with  non-zero  demand 

• Step  2.1:  If  sum  of  individual  demands  <_  total  bandwidth,  allocate  as 
requested;  END 

• Step  2.2:  If  sum  of  individual  demands  > the  resource  capacity,  go  to  Step  3 

• Step  3:  Divide  the  total  bandwidth  to  the  number  of  connections  in  the  set 
generated  at  Step  1:  This  generates  the  Fair  Share 

• Step  4. 1 : For  all  connections  with  individual  demand  < Fair  Share . 
allocate  bandwidth  to  cover  the  entire  individual  demand 

• Step  4.2:  If  cannot  perform  4. 1 , allocate  the  Fair  Share  to  all  connections 

• Step  5:  Find  remaining  bandwidth  after  allocating  in  Step  4.1,  go  to  Step  6 

• Step  6:  Re-start  from  Step  3 with  non-zero  demand  connections  for  which 
bandwidth  not  allocated  yet,  and  the  total  bandwidth  as  calculated  at  Step  5 

• Better  than  EB  in  satisfying  connection  requests  and  in 
minimizing  the  waste  of  bandwidth 
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• Most  Delayed  Queue  Served  First  Bandwidth 
Allocation  (MDQSF) 

• Step  1 : Sort  connections  in  the  decreasing  order  of  the  delay 
encountered  by  the  packet  in  the  head  of  the  queue 

• Step  2:  Allocate  bandwidth  starting  with  the  first  queue  in  the 
ranking  generated  at  Step  1 

• Step  3:  Repeat  Step  2 until  either  the  entire  bandwidth  is 
allocated  or,  all  connections  have  received  service 


DshcH 


NOC  Simulation  Experiments 


C++  and  Matlab  environment 

Queue  model  accuracy: 

• Addition  of  packets  to  the  queue 

• Keeping  copies  of  unACK  messages 

• De-queueing  packets 

• Packet  delay  monitoring 

• Queue  length  monitoring 

State:  queue  length  at  the 
service  facility 


Testing  the  three  strategies: 

• Common  input  data  to  all 
strategies 

• Test  with  the  same  buffer 
space 

• Same  total  bandwidth 

• Same  number  of  sources 
having 

- Same  succession  of 
ON-OFF  periods 

- Same  const,  arrival  rate 


• Service  facility  has  5 queues,  1 for  each  connection 

- Allocation  of  buffer  space  to  each  connection  the  same 

• Packet  received  service  is  sent  over  the  satellite  channel; 
a copy  is  maintained  for  acknowledgment 


497 


tion  Exp 


I 


• Following  quantities  computed,  stored  and  shown  graphically 

• Connection  State:  Busy  (1)  or  Iddle  (0);  All  connections  use  the 
same  constant  rate 

• Queue  Length  (per  connection) 

• Demand:  No  of  packets  admitted  in  the  queue;  either  new  packets 
or  ones  that  have  not  received  yet  service 

• Bandwidth:  No  of  packets  that  a queue  is  allowed  to  output  at  a 
time;  It  depends  on  the  bandwidth  allocation  policy;  Packets  sent  to 
satellite  link  not  deleted  from  queue  until  ACKed 

• Delay:  Delay  by  a packet  sent  out  and  not  yet  ACKed 

• ACKed:  No  of  packets  sent  and  acknowledged 

• UnACKed:  No  of  packets  sent  and  un-acknowledged 


NOC  Simulation  Results 


• Comparison  of  Bandwidth  allocation  strategies 


Buffer  per  Connection 

500  packets 

Total  Bandwidth 

15  packets/unit  time 

Number  of  Connections 

5 connections 

Constant  Arrival  Rate 

10  packets/unit  time 

Mean  of  the  Uniform  Arrival  Rate 

5 packets/unit  time 

Delay  Imposed  to  Queued  Packets 

0.1  unit  time 

Common  Input  Data 


Connl: 

1.4469 

1.4468 

0.0 

Conn2: 

2.0720 

2.0720 

0.5298 

Conn3: 

1.6941 

1.6689 

0.204 

Conn4: 

2.0541 

2.0524 

0.0741 

Conn5: 

1.7182 

1.7088 

0.8847 

;bmw 

EB 

FB 

MDQSF 

Average  Delays 


Analytical  models  and  simulation  can  be  used 
for  Network  Dimensioning: 

Estimate  No.  of  sources  that  can  be  in  the  system 
at  the  same  time 
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Automatic  TCF 


Pittsburg 


http://www.psc.edu/netv 


MotivatTor 

• Conventional  Tuning  i i 

- System-wide  tuning  by 

- Hand-tuning  of  individi 

• Want  each  TCP  connec 
possible  performance  v 
configuration 

• No  need  to  modify  exis 
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Buffer  Tuning 


Sender 

AppData  Send  Buf 


Receiver 


TCP/IP 


Sender 

AppData  Send  Buf 


Under-buffering 


Ack  20  Ack  21 


Ack  22 


Ack  20  Ack  21 


Ack  22 
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Auto-tuning 


Automatic  sizing  of  socket  buffers  for  TC&connections 

- no  manual  configuration  necessary 

- prevents  slow  transfers  resulting  from  in  appropriate  1 

- prevents  mbuf  exhaustion  when  many  concurrent  connection  • 

Receiver  auto-tuning  same  as  over-buffered  receive  sic 
buffer!  'yg 

- Only  the  occupied  part  of  the  buffer  uses  memory,  not  the  full  \ 

advertised  buffer  size  1 

- Never  holds  more  than  one  cwnd  of  data  (just  like  if  it  were  hand- 
tuned  for  performance!) 
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sb_net_target  vs>qwnd  over  time 


► sb_net_target  indicates  the  intended^gnd  buffer 
size  for  a particular  connection  based^fc^a/nH  but 
may  not  be  attainable  if  memory  is  limi 
compared  to  needs  of  connections 

Small  connections  (sb_net_target  < fair  share) 
allocation  they  want,  donating  the  difference 
pool  for  other  connections  to  use. 

Large  connections  (sb_net_target  >=  fair  share)  get 
only  the  fair  share. 


to 


20  30  40 

sec 


• cw  nd 

[ sb_net_target 
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Illustration  of  fafrsfiare  algorithm 


Memory  poof  for  TCP  sender  sdfcket  buffers 
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Basic  Functionality  Test 

• From  1 to  30  concurrent  connectio 
in  Pittsburgh  to  receiver  in  San  Diego 

• 40  Mbps  bottleneck  link,  68  ms  delay 
- 340  kB  bandwidth  delay  product 

• Under-buffered  (default)  tuning  = 16kB  send 
socket  buffer 

• Over-buffered  (hiperf)  tuning  = 400kB  send 
socket  buffer 

• Automatically  tuned  buffers 
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Mbps 


Similar  to  Basic  Functionality  jfesL  1 
the  connections  now  go  from  the  ra 
sender  to  a local  Pittsburgh  receiver 

Local  connections  have  a 10Mbps 
bottleneck  link,  with  ~lms  delay 
- 1 .25  kB  bandwidth  delay  product 
Same  connection  types 


Diverse  concurrent  connections 

\ 
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Conclusion 

v"x. 

• Better  performance 

• More  concurrent  connections 

• Great  for  servers  that  have  many 
connections  over  very  diverse 
bandwidth*delay  paths 


508 


Improving  TCP  Performance  Over  Mobile  Satellite  Channels: 
The  ACKPrime  Approach 


Keith  Scott  and  Stephen  Czetty 
Jet  Propulsion  Laboratory,  California  Institute  of  Technology 
htto://eis.ipl.nasa.gov/~kscott 

NASA  Lewis  Satellite  Networks  Workshop 
June  1998 


NASA  Lewis  Satellite  Networks  Workshop  6/98 


Outline 


TCP  Over  Mobile  Satellite  Links 

- Target  Application:  Once  a packet  crosses  the  satellite  link  it’s  gone  forever. 

- Control  Loop  Includes  Satellite  Delay 

Ways  of  Breaking  the  Control  Loop  at  the  Groundstation 

- Proxy 

- I-TCP 

- Spoofing 
O ACK’ 

ACK’  Implementation 

- Doesn’t  Break  TCP  End-2-End  Semantics 

- Requires  Few  Resources  at  the  Groundstation 

- Requires  Minimal  Changes  to  Sending  TCP 

- ACK’  Can  Provide  Corruption  Notification  at  Little  Extra  Cost 

- IPSec  Breaks  ACK’  Too 
Ack’  Performance 

- Not  as  good  as  Proxying 

- Most  Gain  During  Siow-Start 

- Increased  ACK  Traffic 

- Be  Careful  To  Not  Violate  Congestrion  Control 

NASA  Lewis  Satellite  Networks  Workshop  6/98  Kl 
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TCP  is  responsible  for  reliable,  in-order,  end-2-end  delivery  of  information  without 

duplications. 

- Number  every  byte;  transmit  bytes  along  with  numbers,  get  acknowledgments  from 
the  receiver. 

Window-Based  Flow  Control  & Congestion  Control 

- Receiver’s  Offered  Window  ( Flow  Control ) 

- Sender’s  Congestion  Window  ( Congestion  Control ) 

- Sender  can  have  at  most  MIN(cwnd,  awnd)  unacknowledged  packets  outstanding 
at  any  one  time. 

Slow-Start 

- To  keep  a pair  with  a large  awnd  from  injecting  huge  bursts  of  traffic  into  the 
network,  cwnd  starts  at  1 and  opens  by  1 packet  for  every  ACK  received. 

• Sender  sends  1 packet,  waits  for  ACK,  sends  2 packets,  waits  for  ACKs, . . . 

Congestion  Avoidance 

- When  a loss  is  detected,  halve  the  sending  rate  and  open  cwnd  by  1 packet  for 
every  window  of  data. 

Assumptions: 

- All  losses  are  due  to  congestion  within  die  network  (i.e.  overflows  in  router 
queues). 

- Delay  * Bandwidth  product  is  < 64k  bytes  ( Can  be  circumvented  ) 

- Delay  is  small 


NASA  Lewis  Satellite  Networks  Workshop  6/98 


TCP  Slow-Start 


Sequence  # 


Reno  TCP 

420ms  RTT 

1 Mbps  Bottleneck  Link 


cwnd  limits  transmission 
rate  for  the  first  part  of  the 
connection. 


awnd  =110  packets 


NASA  Lewis  Satellite  Networks  Workshop  6/98 
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Ways  of  Breaking  The  TCP  Connection 
At  The  Groundstation 


- The  mobile  places  a request  with  the  proxy,  the  proxy  executes  the  request  and 
retrieves  the  information,  the  proxy  passes  the  information  back  to  the  user. 

Indirect-TCP  (I-TCP) 

- Similar  to  proxying;  source  sets  up  connection  with  intermediate  node  which 
terminates  the  connection  and  opens  a new  one  to  communicate  with  the 
destination. 

Spoofing 

- The  groundstation  / gateway  actually  acknowledges  data  flowing  towards  the 
mobile  and  suppresses  acknowledgments  from  the  mobile  towards  the  server.  The 
groundstation  really  should  take  responsibility  for  delivering  packets  it  has 
acknowledged. 

ACK’ 

- The  groundstation  / gateway  provides  extra  information  to  the  sender,  in  the  form 
of  ACKPrime’s. 

• Sender  treats  ACK’  like  a regular  acknowledgment  for  the  purposes  of 
increasing  cwnd. 

* Mobile  is  still  responsible  for  acknowledging  data  receipt. 


NASA  Lewis  Satellite  Networks  Workshop  6/98 


ACK’  Implementation 


Simulated  a version  of  ACK’  in  lbl’s  network  simulator  (ns). 

- Modified  snoop  and  NewReno  elements  to  be  an  ACK’  gateway  and  an  ACK’- 
capable  sender. 

- Gateway  keeps  no  state,  it  simply  generates  ACK’  packets  whenever  it  forwards  a 
TCP  packet  across  the  satellite  link. 

- Topology  includes  10Mbps  terrestrial  network  with  10ms  delay  and  2Mbps  satellite 
network  with  200ms  delay. 

• No  contention  for  the  terrestrial  network  or  buffer  space  yet. 

* Assumes  properly  tuned  windows  & socket  buffers 


Planned  Improvements 

- Don ’t  violate  congestion  control ! 

- Use  ACK’  information  along  with  regular  acknowledgments  to  get  (expensive) 
corruption  notification. 

- Modified  ACK’  scheme  to  reduce  acknowledgment  traffic 

- Ways  around  IPSec. . . 

Plan  a kernel  implementation  on  JPL’s  mobile  satellite  protocol  testbed  later  this 


NASA  Lewis  Satellite  Networks  Workshop  6/98 
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Transport  Protocols  for  IP- 
Compatible  Satellite  Networks 


Tom  Henderson 

(tomh@cs.berkeley.edu;  www.cs.berkeley.edu/~tomh) 

and 

Randy  Katz  (randy@cs.berkeley.edu) 

NASA  Lewis  Satellite  Workshop:  June  2-4,  1998 

Dept,  of  Electrical  Engineering  and  Computer  Science 
University  of  California  at  Berkeley 


Future  broadband  satellite  systems 

Last-hop  IP  access  is  our  service  focus 

• Hybrid  GEO/LEO  systems  are  envisioned 

• Potentially  highly  asymmetric  access 

• GEO  assumptions 

- Low  BER  (improved  coding,  higher  power), 
high  availability,  but  high  RTTs 

• LEO  assumptions: 

- Lower  average  RTTs  (<  200ms),  but  higher 
RTT  variance  (due  to  handoffs),  higher  BER 
and  lower  availability  (fading  links) 
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TCP  tradeoffs 

• Two  basic  strategies  for  improving  satellite 
TCP  performance: 


End-to-end  changes 

• Preserves  end-to-end 
semantics 

but 

• deployment  is  a major 
problem 

• some  RTT-related  problems 
cannot  easily  be  solved  for 
heterogeneous  networks 


TCP  gateway 

• Minimizes  host  changes 

• Reduces  RTT  problems 

but 

• adds  complexity  to  satellite 
networks 

• may  be  hindered  by  IP 
security  protocols 


Outline 

• End-to-end  TCP  performance 

- implementation  performance  of  SACK 

- TCP  congestion  avoidance  problems 

• Satellite  Transport  Protocol  (STP) 

- design  goals 

- file  transfer  performance 

- HTTP  1.0  performance 


518 


• All  machines  running  BSD/OS  3.0  with  large  windows 

• Routers  do  not  send  source  quench 


100  Mb/s  10  Mb/s  10  Mb/s 

Ethernet  Ethernet  Ethernet 


Performance  of  3 TCP  variants 

• Averages  of  20  file  transfers  of  10  MB  each 


• SACK  NewReno  maintains  high  throughput,  while  SACK 


1 00  Mb/s  10  Mb/s  10  Mb/s  Background 

Ethernet  Ethernet  Ethernet  sink 


Effect  of  short-delay  flows 

• A single  short-RTT  (20ms),  large  window  flow  can 
significantly  degrade  satellite  connection’s  performance 


RTT  (ms) 
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Summary 

• For  GEO  links,  small  variations  in  TCP 
implementations  can  have  major  effects 

• Even  light  congestion  in  wide  area  network 
can  significantly  degrade  satellite  TCP 

- well-known  fairness  problem  of  TCP  congestion 
avoidance 

- multiple  (slow-starting)  short  flows  have  an  even 
worse  effect 

• Short  (HTTP)  satellite  connections  perform 
even  worse  than  file  transfers  due  to  slow-start 


Alternative  transport  solutions 

• What  type  of  protocol  is  best  for  split 
connections  or  internal  satellite  traffic? 


Satellite-optimized 
transport  protocol 
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Satellite  protocol  requirements 

• High  efficiency  in  forward  direction 

- selective  acknowledgments  (very  few  unnecessary 
retransmissions) 

• Minimize  bandwidth  in  reverse  direction 

- better  for  asymmetric  environments 

• Minimize  protocol  handshaking  latency 

• Allow  for  rate  controls  in  addition  to  window 
controls 

• Compatible  with  TCP  (interworking  and  API) 


Satellite  Transport  Protocol  (STP) 

• An  ATM  link  layer  protocol  known  as 
SSCOP  already  has  many  of  these  attributes 


TCP  (transport  layer) 

- “fast  retransmit” 


SSCOP  (link  layer) 


- error  recovery 
mechanism 


Further  modifications 


- congestion  control 
mechanism 

- connection  control 


Satellite  Transport  Protocol  (STP) 
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Basic  STP  operation 


Transmitter  Receiver 


STAT 


USTAT  (Receiver 
detects  loss  of  #7) 

STAT  (again  reports 
#7  missing) 


Full,  periodic  state  exchange  is  the 
basic  design  philosophy 


STP  improvements  over  SSCOP 

• STP  handles  data  misordering  by  network 

• For  congestion  control,  STP  implements 
traditional  TCP-like  window  control,  rate 
control,  or  hybrid  approaches 

- no  congestion  control  for  SSCOP 

• Fast  connection  setup  (like  T/TCP)  is  the 
default  behavior 

• Concatenation  of  PDUs  (e.g.,  piggybacked 
POLLs)  performs  better  in  Internet 

• STP  supports  full  TCP  API 
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Experiment  methodology 

• Split  end-to-end  connection  at  user  level  at  gateway 


For  fair  comparison,  STP  implemented  TCP  slow-start, 
congestion  avoidance,  and  exponential  backoff 


D 


Source 


P 


Background 

source 


FIFO  router 
size=50 


FIFO  router 
size=50 


TCP/STP  gateway  \ Sink 
(split  connection)  \ 


□ 


Link  emulator 


Bottleneck 


(1.3  Mb/s, 
variable  delay) 


100  Mb/s  10  Mb/s 

Ethernet  Ethernet 


10  Mb/s  Background 
Ethernet  sink 


STP  performance:  bulk  transfers 

Both  TCP  SACK  and  STP  can  reduce  fairness  problems  by 
splitting  the  connection 


524 


STP  performance:  bulk  transfers 

9 However,  STP  uses  much  less  of  the  reverse  channel 
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STP  performance:  transactions 

• Average  of  1000  simulated  HTTP  transfers  over  600 
ms  channel 

• Traffic  generated  based  on  empirical  distributions 
derived  from  HTTP  traces 

• STP  performance  approaches  that  of  T/TCP 

- Traffic  smoothing  accounts  for  larger  latency 

- To  speed  window  buildup,  every  packet  had  a piggybacked 
POLL  if  the  congestion  window  <=  10  segments 


Avg.  latency  (s) 

TCP 

2.0 

12.3 

T/TCP 

1.4 

7.3 

STP 

1.7 

8.9 
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Mil 


Cheryl  DeMatteis,  Michael  O'Brien,  James 
Stepanek,  Scott  Michel,  Cauligi 
Raghavendra  and  Michael  Campbell 

The  Aerospace  Corporation 

Robert  Lindell  and  Joseph  Bannister 

USC  Information  Sciences  Institute 


An  Opportune 


High  Bandwidth 

Small  Low  Cost  Reception  Devices 
Internet  Connectivity  and  Interoperability 
Large  Base  of  Application  Software 
USAF  Global  Broadcast  Service  (GBS)  Program 
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• High  Power  Transponders 

• Small  Antenna  With  Fixed  Orientation 

• Wide  Geographic  Range 

• Unidirectional  Broadcast  Bandwidth 


Consumer  DBS  Equipment 


• 18"  Dish,  Set-Top  Box,  Smartcard 

• Reed  Solomon  and  Viterbi  Convolution 
Codes  for  Forward  Error  Correction  (FEC) 

• 40  Mb/ sec  Without  FEC 

• 20  - 30  Mb/s  With  FEC  (10e-8  BER) 

• High  Speed  Serial  Port  Interface 
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• DARPA/ISO  Advanced  Concept  Technology 
Demonstration  (ACTD) 

• 6 Months  of  Development,  1 Year  to 
Deployment  for  Each  Phase 

• Our  Focus  is  on  the  Advanced  Data 
Dissemination  Methods 

• DBS  Links  are  Part  of  a Larger  Internet 

• Exploit  Multicast  Capabilities 
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• IP  depends  on  a bi-directional  link 

• Routing  Protocols  depend  on  a symmetric  link 

• Long  delays  affect  TCP/IP  performance 

• Reliable  Multicast  Transport 

• QoS 


Other  Approaches 


BC2A:  "Spray  and  Pray" 

UDLR:  change  all  routing  protocols 
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Memat 


Improved  Satellite 
Networking  Using  the 
Mentat  SkyXpress  Protocol 


DC  Palter 
Mentat  Inc. 

dc@mentat.com 

http://www.mentat.com 


NASA  Lewis  Workshop  June  1998 
Satellite  Networks:  Architectures,  Applications,  and  Technologies 


Mental 


SkyX  Presentation  Outline 


Mentat  Background 
Satellite  Conditions 
SkyX  Design 

SkyX  vs.  TCP  Performance  Testing 

▲ By  NASA  Goddard 
a By  Mentat 

SkyX  to  TCP  Integration 
Q & A 
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networking  source  code  to  computer  and 
embedded  operating  system  vendors  since  1987 

The  native  TCP/IP  in  the  following  operating 
systems  is  based  on  Mentat  TCP: 

a Hewlett-Packard  HP-UX 
a Sun  Solaris 
a Apple  MacOS 
A Sony  NEWS 

a Motorola  SVR4  Unix,  VMExec 
a Concurrent  PowerMaxOS 
a Others 


IVIentat 


GEO  Satellite  Conditions 


> Large  Latency 

a Satellite  hop  round  trip  time  of  ~0.5  seconds 

• High  Error  Rates 

a Bit  Error  Rates  of  lxl 0‘10  to  lxlO-6 

» Asymmetric  Bandwidth 

a Back  channel  bandwidth  generally  a fraction  of  the  forward 
channel  bandwidth 

► Point-to-Point  Connection 

a Satellite  link  generally  point-to-point  connection  with  no  routing 

Causes  Poor  Performance  of  TCP  over  Satellites 
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Mentat  SkyXpress 
Protocol  Design 


Selective  Retransmission  Algorithm 

▲ Lost  or  corrupted  data  triggers  immediate  NACK  and  retransmit. 

▲ Sender  periodically  polls  receiver  for  data  acknowledgment. 

Large  Windows 

▲ 64  bits  used  to  specify  window  size. 

Appropriate  Start-Up  Strategy 

▲ No  start-up  ramp  for  point-to-point  hop  over  satellite. 

Rate  and  Burst  Control 

a Maximum  allowable  bandwidth  can  be  set  on  per-connection  basis. 
a Avoid  overrunning  known  bandwidth  bottleneck. 


f 

Mentat  Mentat  SkyXpress 

Protocol  Design  (Con’t) 


Efficient  Design 

a Streamlined  handshake  reduces  connection  overhead. 

A 64-bit  design. 

Reliable  Multicast 

a Transport  level  reliable  multicast  for  efficient  point-to-multipoint 
communications. 

Runs  over  IP  or  Link  Layer 

a Runs  over  IP  when  routing  required. 

a Runs  over  link  layer  for  maximum  efficiency  on  point-to-point  link. 
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Mentat 


SkyX  Performance  Testing 


NASA  GSFC 

SkyX  vs.  TCP  Performance  Comparison 

Compared  SkyX  to  TCP  and  TCP-SACK 

Testing  by  NASA  Goddard  Space  Flight  Center 
High  Performance  Computing  and  Communications  Group 
Testbed  for  Satellite  and  Terrestrial  Interoperability  Project 
http://everest.gsfc.nasa.gov/ 

Simulated  large  file  transfer  over  satellite  link 

50  test  runs  for  each  BER  and  latency  data  point 

Data  normalized  by  max.  measured  throughput  of  128  Mbps 


Mentat  SkyX  Performance  Testing 
NASA  GSFC 

SkyX  vs.  TCP  Test  Network 


OC-3  Line 


I 

FORE  OC-3 

Sun  Workstation  Switch 


Adtech  SX/14 


JSSS, 

Switch  Sun  Workstation 


CPU 

Operating  System 

TCP  Implementations 

TCP  new-Reno,  TCP-SACK 

Network 

Line  Speed 

OC-3  (155  Mbps) 

Satellite  Link  Simulator 

Adtech  SX/14 
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SkyX  and  TCP  Throughput  vs.  BER 
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SkyX  and  TCP  Throughput  vs.  BER 
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Throughput 

(Mbps) 


IVIentat 


SkyX  on  the  LAN 


SkyX  and  TCP  Throughput  vs.  BER 

LAN  Conditions:  RTT  = 1 ms 
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Mentat  Additional  SkyX  Testing 

Performed  at  Mentat 


SkyX  and  TCP  Throughput  vs.  BER 


* i 
% 


o.o 

IE-10 


■-  TCP/IP 


IE-9  IE-8  IE-7 


Test  Conditions 


Bit  Error  Rate 


Windows  NT  3.51 
Sat.  Link  Simulator: 


Mentat  HAVOC 
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• Transparent 

▲ No  changes  to  end  client  and  server  TCP  stacks. 

• Available 

a Does  not  require  wide-spread  roll  out  of  modified  TCP. 

• Safe 

A Maintains  TCP  connection  reliability  and  end-to-end  semantics. 

• Internet  Friendly 

a Maintains  congestion  control,  slow  start,  etc.,  over  terrestrial  links. 

• Supports  All  Data  Traffic 

a Provides  bridging  for  UDP,  IPX,  SNA,  all  other  protocols. 


Mentat  SkyX  to  TCP  Integration 

SkyX  Gateway  Architecture 


Browser 


Client  SkyX  Gateway 


SkyX  Gateway  Server 


Web  Server 


TCP 


TCP  PEP  Module 


TCP  PEP  Module 


SkyX 


SkyX 


TCP 


Driver 


To  Gateway  I To  Client  I To  Satellite  i 


Driver  Driver 


To  Satellite  ( To  Server  | |To  Gateway 
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tegration 


Satellite 

Connectivity 


LAN  Based  Satellite 
Connectivity 


SkyX/  \SkyX 


li 


Server 


ISP  Satellite 
Connectivity 


Mentat  Gateway  System  Testing 


SkyX  Gateway  and  End-to-End  TCP 
Throughput  vs.  BER 


Test  Conditions 


jimMlEffl  ill 


forward:  400  kbps 
reverse:  128  kbps 


I IJuI4 
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• SkyX  Gateway 
- End-to-End  TCP 


Bit  Error  Rate 


Mentat  HAVOC 
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Conclusion 


Mentat  SkyXpress  Protocol 
provides  a transparent, 
high-performance  solution  for 
Internet  access  over  satellite  links. 


SkyX  is  available  now  from  Mentat. 

more  information  available  at: 

http://www.mentat.com/Documentation/white__papers/skyx.html 
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Future  Applications,  Technology 
and  Architectures 


Edward  W.  Ashford 
Lockheed  Martin 

June  4, 1998 


FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 

■ "IT  IS  EASIER  TO  PREDICT  THE  PAST  THAN  THE  FUTURE" 
(AND  EVEN  THEN,  SOME  GET  IT  WRONG!) 


- "THOSE  WHO  DO  NOT  KNOW  HISTORY  ARE  CONDEMNED  TO 
REPEAT  IT"  (AND  THOSE  THAT  DO.. .SOMETIME  REPEAT  IT 
AS  WELL!) 


■ THEY  SAID  TO  CHEER  UP,  SINCE  THINGS  COULD  BE 
WORSE.  SO  I DID,  AND  SURE  ENOUGH,  THEY  WERE 
RIGHT.. .THINGS  GOT  WORSE. 
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FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 


■ "THROUGH  A CRYSTAL  BALL  DARKLY",  OR  "THE  PITFALLS 
OF  TREND  PROJECTIONS" 

► THESE  ARE  SUBJECT  TO  SEVERAL  (OFTEN 
INTER-RELATED)  EFFECTS  WHICH  CAN  MAKE  A 
PREDICTION  COMPLETELY  WRONG,  INCLUDING: 
-LACK  OF  UNDERSTANDING  OF  THE  DETAILS  OF  THE 
SYSTEM  CONCERNED 
-INADEQUATE  DATA 
-OGIVE  TENDENCY 
-BUBBLE  BURST  EFFECT 


FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 

■ GIVEN  THE  ABOVE  EXCUSES  FOR  MAKING  INACCURATE 
PREDICTIONS,  AND  WITH  APOLOGIES  FOR  THE 
"NOSTRODAMUS  OUT" 
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FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 


■ THE  ARCHITECTURES  OF  THE  FUTURE  WILL  BE  THOSE 
THAT  SUPPORT: 

► ANYWHERE  TO  ANYWHERE  CONNECTIVITY 

► SATELLITE  SYSTEM  TO  SATELLITE  SYSTEM 
INTEROPERABILITY 

► SEAMLESS  INTEGRATION  WITH  TERRESTRIAL  SYSTEMS 
(INCLUDING  SEAMLESS  PRICING!) 


FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 

• WHAT  IS  THE  "KILLER  APPLICATION”  OF  THE  FUTURE  FOR 
SATELLITE  COMMUNICATIONS? 

■ ANSWER: 

► AN  INTERNET  ROUTER  IN  THE  SKY,  COMBINED  WITH... 

► REAL  TIME  LANGUAGE  TRANSLATION  FROM  AND  TO  ANY 
LANGUAGE 
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FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 

■ WHAT  TECHNOLOGIES  WILL  BE  NEEDED? 


■ THE  FIRST  WILL  BE  A CHANGE  OF  MIND-SET  IN  THE 
REGULATIONS,  TO  RECOGNIZE  THAT,  IN  A DIGITAL  WORLD, 
THERE  IS  NO  DIFFERENCE  BETWEEN  BITS  THAT  CARRY 
FIXED,  MOBILE,  BROADCASTING,  NAVIGATION  OR  DATA 
RELAY  SERVICES  INFORMATION.  FOLLOWING  THAT: 


FUTURE  APPLICATIONS,  TECHNOLOGY 
AND  ARCHITECTURES 

■ TECHNOLOGY  NEEDED: 

■ ON-BOARD: 

► OPTICAL  SIGNAL  PROCESSING  AND  BEAM  FORMING 

► GREATLY  IMPROVED  ON-BOARD  TRANSMITTER 
EFFICIENCIES  AT  Ka-BAND  AND  ABOVE 

► PROTOCOL/STANDARDS  CONVERSION 

► DYNAMIC  BANDWIDTH  ON  DEMAND  ALLOCATIONS  OF 
RESOURCES 

■ ON-GROUND: 

► CHEAP  AND  EFFICIENT  MULTI-BAND  TERMINALS 

► FAST  AND  ACCURATE  LANGUAGE  TRANSLATION 
ALGORITHMS 

► (IMPROVED)  MULTI-SYSTEM  TERMINALS 
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NASA’s  Commercial  Communications 
Technology  Program 

Presented  to: 

The  Workshop  on  Satellite  Networks: 

Architectures,  Applications,  and 
Technologies 

Cleveland,  Ohio 
June  2-4,  1998 
by 

Janies  W.  Bagwell 
Lewis  Research  Center 


Vision 


“Changing  the  way 
NASA  and  the  Nation 
communicate  through  space” 
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Mission 

- Enable  NASA’s  Use  of  Commercial  Satellites  for  All 
Its  Operational  Needs  In  and  From  Space 

• Ensure  Availability  of  Commercial  Assets 

• Reduce  NASA  Operations  Costs 

- Promote  Communications  Satellites  for  the 
Maximum  Benefit  to  Society  through: 

• Increased  Economic  Security 

• Cost  Effective  Services 

• Universal  Availability 

• Capable,  Reliable  Communications  for  All  Government  Users 


LeRC  Space  Communications  Program 


Commercial  LEO/MEO/GBO 
Satellite  Networks 


SIM 


SmsMilMM 


• Lead  Center  for  spectrum 
management 

• Enabling  technology  for  high- 
performance  comm  systems 

• Investment  leverage  from 
-SatCom  Industry  sector  & OoD 


LeRC  SCP  Vision2a.ppt 
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( Global 
Comm 
Network  n 
Environment) 


NASA . J 
'■Space 
Missions  ■ 
In  ' 

Future, 


s of  S 


i SATCOM 
Architecture 
-Post  TDRSS\ 
_ 2010 . / 


Enabling  A 
Technology  ] 

Hardware  A 
Network  >.  1 

Stds/ProtocolY/  ^ 
Spectrum  j 
i Etc.  h — ' Implementation 
Plan 


DoD 

Space 

Archltecb 

Vision 


^DoD 

Space 

Mission 

In 

Future 


■ Implementation 
Plan 


__  Government  Led  Programs  Elements  and  Objectives  for 
§88  Satellites  in  Global  Information  Infrastructure 

Lawii  Research  Ccn 


A.  Coordinate/Integrate  Government  Program 
(NASA,  DoD,  etc.) 

• Use  government  “Space  Technology  Alliance”  - 
AF  Research  Lab,  NASA,  NRO,  DDR&E, 
BMDO,  ONR 

• Coordinate  with  “Satellite  Alliance”  for 
industry/academic/govemment  interaction  and 
program  development. 

• Government  led  workshops 
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B.  Achieve  Seamless  Interoperable 
Satellite  & Terrestrial  Networks 

• Implement  via  architectures,  standards,  & 
protocols. 

• Develop  and  adopt  commercial  standards  in  close 
cooperation  with  industry  (e.g. 
Telecommunications  Industry  Association) 

• Perform  experiments  & validation  testing  (GIBN, 
ACTS,  etc.) 

• Develop  next  generation  architectures  with  goal  of 
global  interoperability. 


Government  Led  Programs  Elements  and  Objectives  for 
Satellites  in  Global  Information  Infrastructure 


C.  Establish  Program  to  Enhance 
Satcom  Professional,  Technical  Workforce 

• Meet  needs  of  Communications  Satellite  Industry. 

• Involve  Universities,  Govt.  Research  Labs,  and 
Industry. 

• Integrate  with  Precompetitive  Technology 
Program 


Program  Development  Discussion  - Tue.  June  2 
O’Hare  Room,  3:30pm 
Ms.  Joanne  Poe,  Moderator 
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• Vision  - Global  Information  Infrastructure 

• Target  - Next  generation  space-based  networks. 

• Integrated  commercial  and  government  customers 

• Goal  - Prioritized  program  plan 

• Participants  - Academia/Govemment/Industry 

Program  Development  Discussion  - Wed.  June  3 
O’Hare  Room,  3:30pm 
Dr.  Charles  Raquet,  Moderator 


Government  Led  Programs  Elements  and  Objectives  for 
Satellites  in  Global  Information  Infrastructure 

Ltwa  ReMarth  Cot 


E.  Effective  Utilization  of 
Spectrum  & Orbit  Assets 


• Create  commercial  satellite  conducive 
national/intemational  regulatory  environment. 

• Advance  govemment/non-govemment  shared 
spectrum 

• Share  satellite/wireless  terrestrial  communications 
services 
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Satellite  Networks: 
Applications,  Architectures, 
and  Technologies  Session, 
June  4, 1998 


William  Bailey 
Business  Development, 

New  Markets  & Technologies 

Cisco  Systems 


Cisco  Systems 


VWetay  - New  Maifcets  and  Technology** 


“Calm  down,  it’s  only 
ones  and  zeros” 

Bumper  sticker  seen  in  Silicon  Valley 


Cisco  Systems 


Vl£  B Naw  Martat*  end  Technology**  2 
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ones  and  zeros! 


WES  New  Maricets  and  Tectrnotofli*  * 3 


Waves  of  IP  Traffic  Growth 


Rel.  Bit  Volume 
250  -I 


* Web  Access,  E-mail 

• Business  to  business 
Ecommerce 

• Voice  Over  IP/ATM/Frame 
Relay 

* Business  Video 

* Consumer  Ecommerce 

• Entertainment 

- Digital  Video,  gaming 


1997  1998  1999  2000 

Traffic  Projections  for  Voice  and  Data 


“From  2000  on,  80%  of  service  provider  profits  will  be 
derived  from  IP-based  services,  — ciMiCorp. 


Cisco  Systems 


WEB  Naw  Marinis  and  Technologies  A 
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Growth  Enabling  Technologies 

• DSP  + processor  cores 

Driven  by  wireless  handset  market 
Enables  low  cost  voice/video/data  gateways 

9 Faster  packet  engines/architectures 
Complex,  high  performance  ASICs 
Parallel  computing  architectures 

• Optical  technologies 

• Network  Techniques  ! 


Cisco  Systems 


WEB  New  Markets  and  Technologies  5 


Networks  Today 

LAN  Cam 


Multigigabit,  Wire  speed, 
Layer-3  (IP,  IPX)  Switching 

IP  Multicast  support 

Pull  service  routing  support , 

Extensive  QoS  capabilities 

Feature  rich  access  Control 
Lists  (SWand  HW) 


Internet 


Cisco  Systems 

WEB  New  Maricet*  end  TechndogM*  8 
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Speed  and  intelligence 


• Low  cost  switching 

• Routing  @ line  rate 

• QoS  @ line  rate 

• Multicast  @ line  rate 
•Security  @ line  rate 


* Policy-Based  Networks 
•Application  awareness 

• Increased  availability 


Tast  EtherChanneY 
Technology 


20  Mbps 

200  Mbps  800  Mbps  2000  Mbps 

8000  Mbps 

Cisco  Systems 

Increasing  Speed  at  Full  Duplex 

Cisco  Systsms 

New  Markets  and  Teehnoiogiss  7 

WAN  Enhancements 

• Terabit  speed  Hybrid  Switch/Routers 

Packet  over  SONET  OC192  Interfaces  in  the  near  future... 
High-speed  architectures  allow  IP  QOS,  multicasting,  etc 

• Direct  WDM  Optical  Internetworking 

Replaces  TDM,  lowers  costs  by  at  least  2/3,  increases 
“fiber  gain”  capacity  in  the  order  of  8-32x 

Will  eventually  extend  to  customer  premises 

Optical  technology  will  be  integrated  into  core  of  hybrid 


switch/routers 


Cisco  Systems 


VEB  N«w  Markatc  and  Tschnotogtst  6 
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Network  Techniques 

• Quality  of  Service  (QOS) 

Tagging,  Coloring,  Labeling 

ToS  precedence  bits  allows  traffic  classes 

Congestion  Management  (WRED,  WFQ) 

• Policy  Networking 

Priority/QOS  Enforcement 
GUI  Applications 

• Multicasting 

• Web  and  Application  Caching 


Cisco  Systems 


WEB  N*w  Mirtwt*  and  T*cftnok»fli#*  9 


The  Leaves  on  the  Tree 


• Local  loop  is  a potential  gold  mine 

Small  business  are  waiting 

Positive  consumer  spending  indications 

Applications  & content  are  waiting 

• Someone  PLEASE  fix  the  local  loop! 

• Regulation,  a potential  dark  cloud  over 
growth 


Cisco  Systems 


WEBrMwMarttaUandTKhmtoglMM  10 
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Applying  Terrestrial  Network 
Technology  to  Satellites 


•Net  Management 
■DNS/DHCP 
'Statistics  gathering 


Net  Control 


Cisco  Systems 


Nmw  Marfeata  end  T«hnofe>9t»»  1 1 


• Satellite  system  designers  and  terrestrial 
network  vendors  need  to  engage  and  partner 

Too  Song  of  a delay  from  state-of-the-art  terrestrial 
networking  to  the  “top  of  the  rocket” 

9 Space  is  a dangerous  place  - stray  atomic 
particles,  or  is  terrestrial  competition  the 
danger?  ClSC^YSTEMS 


Cisco  Systems 


WEB  Marfwta  sod  T<*c*nob$tts  12 
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Architectures,  Applications,  and 
Technologies 


Orbital  Sciences  Corporation 

Dr.  Joseph  Bravman 

June  4, 1998  NASA  Lewis  Research  Center 

Source:  ITU,  Pioneer  Consulting 

Dr.  Joseph  Bravman 

June  4, 1998  NASA  Lewis  Research  Center 
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• All  Digital  Format 

• Massive  Growth  in  BW 

• Moore’s  Law  Lives  (Computing  Power, 
Storage,  Transmission) 

• Ubiquitous  Connectivity 

• Convergence  of  Services 

• Merger  of  Technology  & Life 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 


Applications 


• Telepresence  (Virtual  Office, 
Telemedicine,  Exploration) 

• Bulk  Transfers  / Backhaul 

• Entertainment 

• Commerce 

• Remote  Sensing 

• Remote  Monitoring  (Multipoint  to  Point; 
Traffic,  Environment) 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 
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Is 


nue 


• Applications  Dominate 

• Capital  Markets  Are  Available 

• Massive  Satellite  Population  in  Space 

• Rationalization  Between  Fiber  / 
Terrestrial  Microwave  / LMDS,  Satcom, 
Etc. 

• Giga-lnternet  Creation 

• Evolution  of  Standards 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 


Satellite  Advantages 


• Supports  Global  Mobility 

• ‘Instant  Infrastructure’  - Solves  ‘Last 
Mile’  Problem 

• Cost-Effective  Over  Large  Areas 

• Flexible  Distribution 

• Flexible  Capacity  - ‘Bandwidth  On 
Demand’ 

• Reliable  Once  On  Orbit 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 
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• LEO  & MEO  Systems 

• Hybrid  Network  Architectures 

• Digital  Compression,  Encryption 

• Chips  Reduce  Size  & Cost  of  Portables 

• On-Board  Processing 

• Ka  & Higher  Band  Components 

• Inter-Satellite  Links:  RF  and  Optical 

• Narrow  Spot  Beams  & Phased  Arrays 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 


Trade  Space 


• LEO  / MEO  / QEO  / Other 

• ISL  or  Not 

• Number  of  Planes-Coverage  / Augmentation 

• Match  to  LV  Size 

• Technology  Drivers  and  Enablers 

• Choice  of  Spectrum 

• Choice  of  Standards 

• Symmetric? , Real-time? 

• On  Board  Complexity 


Dr.  Joseph  Bravman 


June  4,  1998 


NASA  Lewis  Research  Center 
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Satellite  Services  Market 


350 


Global  Commercial  Satellite  Services  Market 


g Fixed  Data 
s Video  Broadcast 
a DTH/DBS 

□ Mobile  Voice  and  Data 


O 


Fixed  Voice 


Dr.  Joseph  Bravman 


Source:  Pioneer  Consulting 


June  4, 1998  NASA  Lewis  Research  Center 


Cumulative  Broadband  Satellite 
Systems  Investment 


Orb 


>$70B 

Over 

Next 

Ten 

Years? 


1993  2000 

2002  2004 

2005  2008 

Source:  Pioneer  Consulting 

Dr.  Joseph  Bravman 

June  4,  1998 

NASA  Lewis  Research  Center 

Satellite  Two-Way  Communications  urn 
^ 

Narrowband  Wideband  Broadband 


Large  Fixed  ! 
Antenna  i 


Public  / 
Backbone 


Small  Fixed 
Antenna 


Handheld  / 
Mobile  Ant. 


“Business  / 
Commercial 


Residential  / 
Consumer 


Source:  Ali  Grami  & Ken  Gordon,  Telesat  Canada 


Dr.  Joseph  Bravman  June  4, 1998  NASA  Lewis  Research  Center 


Access  Technologies  Compared 


Standard  Line  . ISDN  Line  ADSL/T-1  Cable  Modem  Ka  Satellite  Q/V  Satellite 


(16  Megabits) 


(4.3  Gigabits) 


35.7  sec. 

1 .3  sec. 

0.5  sec. 

.25  sec. 

4.8  min. 

10.7  sec. 

4 sec. 

2 sec. 

21.5  min. 

48  sec. 

18  sec. 

9 sec. 

21.4  hrs. 

48  min. 

18  min. 

9 min. 

Source:  Forrester  Research,  PanAmSat 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 
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Q/V  and  Ka  Systems  Compared 


120 


££  60 
o O 40 


Dr.  Joseph  Bravman 


Q/V  Band  Systems  Ka  Systems 

Source:  Pioneer  Consulting,  FCC  Applications 


June  4, 1998  NASA  Lewis  Research  Center 


OrbLink  Trades 

Orbital 

• Keep  St  Simple:  High  Usable  Capacity 
to  Cost  Ratio 

• Consistent  and  Complementary  With 
Terrestrial  Standards 


Dr.  Joseph  Bravman 


June  4, 1998 


NASA  Lewis  Research  Center 
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NASA  Laws  Workshop  - June  4 1998 


TELEDESIC  LEO  NETWORK 
ARCHITECTURE 

Dr  Marie-Josg  Montpetit 
Network  Design  Team 


Future  Network  Requirements 

NASA  Lews  Workshop  - June  4 1998 

■ Broadband  Capacity 

■ Ubiquitous  Access  ' 

- Enable  capacity  everywhere 

■ Quality  of  Service 

- Allow  for  service  differentiation  in  quality  and  pricing 

■ Seamless  integration  into  existing  protocols  and 
infrastructures 
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Satellite  Networks 


NASA  Lewis  Workshop  - June  4 1998 


■ Regional/Global  coverage 

■ Wireless  Interfaces 

- No  need  to  install  “wired”  infrastructure 

■ Onboard  Switching 

- Reduces  delay  for  BOD 

- Allows  multiple  beams  (smaller  terminals) 

■ Can  be  deployed  faster  than  most  terrestrial  infrastructures  into 
regions  with  little  or  no  existing  infrastructure 

■ Can  bypass  clogged  terrestrial  networks  and  is  oblivious  to 
terrestrial  disasters 

■ Increase  existing  network  reliability 


LEO  Satellite  Networks  Features 


NASA  Lews  Workshop  - June  4 1998 


■ Fiber-like  delays 

■ Global  coverage 

■ Integration  in  the  Network  of  Networks 

■ Advanced  communication  services  almost  everywhere,  all  the  time 

■ Low  implementation  cost  per  site 

■ Can  grow  naturally  as  markets  develops 

■ Support  both  symmetrical  and  asymmetrical  applications 

■ Flexibility  while  keeping  a manageable  complexity 
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Teiede^ic:  Interne|»in-tfe^Sky 


NASA  Lewis  Workshop  - June  4 1998 


l[r»nanet?  - Enterprise 


SiiSateway 

-f- :%  ©OOf ' 6 ffi  nCIO 


deifolarBackhaut 

'“’“s 


Gateway 


Existing  Terrestrial  Network  . 


,1 


Telecommuting 


The  Teledesic  Network  Architecture 


NASA  Lewis  Workshop  - June  4 1 


h Low  delay 

- Autonomous  nodes 

- No  need  for  changing  terrestrial 
protocols 

• Impacts  on  congestion  control 

• Impacts  on  IPsec 

• Impacts  on  client  server  applications 

- Interactive/real  time  applications 

■ Seamless  interworking 

- ip 

- ATM 

- SNA 

- New  protocols 

a Global  access  with  high  availability 

- High  mask  angle 

- Dense  meshed  Network  i&fc 


a High  Capacity 

- High  frequency  re-use  added  to 
bandwidth  on  demand  (BoD) 

- SmaH  cells/footprints 

- High  level  of  statistical  multiplexing  in  the 
air  interface 

- Low  delay  allows  very  resource  efficient 
BoD 

« Reliability 

- Engineer  reliability 

- Implements  connectionless  protocols 

- Keep  state  information  at  the  edges 
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Low  Latency  is  Essential  to  the  Internet 

NASA  Lewis  Workshop  - June  4 1 998 

■ GEO  latency  can  significantly  degrade  performance  on  client/server  applications  such  as 
Oracle  and  Exchange  Server  resulting  in  slow  downs  of  10  times  or  more 

- Small  transaction-oriented  queries  get  queued  up  by  GEOs’  high  delay 

■ Companies  on  the  Internet  today  are  guaranteeing  maximum  allowable  latency: 

- ANX  guarantees  < 1 25  msec  end-to-end  for  service  provider  certification 

- UUNET  guarantees  <150  msec  end-to-end  latency  for  two  sites  cm  its  network 

- AT&T  Worldnet  guarantees  <100  msec  latency  on  its  backbone 

- Sprint  guarantees  <140  msec  latency  on  its  backbone 

■ GEOs  do  not  work  well  with  fundamental  Internet  protocols  like  TCP/IP 

- Most  implementations  of  TCP  today  provide  unacceptable  performance  (e.g.,  wasting  93%  of  bandwidth  on 
a 2 Mbps  connection)  because  they  lack  "large  window"  support 

- TCP's  essential  congestion  control  mechanisms  degrade  performance  over  GEOs.  These  mechanisms 
cannot  be  removed  without  potentially  causing  the  "congestive  collapse"  of  the  internet. 

- One  proposed  solution,  ACK  spoofing,  is  incompatible  with  Internet  Protocol  security  (IPsec)  and  will  not 
work  at  all  with  the  next  generation  protocol,  IPv6. 

■ Transaction-oriented  Internet  protocols  also  suffer  from  GEO  delays  because  signaling 
exchange  is  necessarily  sequential 

- HTTP/1. Oand  HTTP/1.1,  POP3, 1MAP4 

- Hand-shaking  portions  of  real-time  protocols  such  as  H.323  also  suffer 


Low  Latency  and  High  Bandwidth  are 
Necessary  for  Fiber-Like  QOS 

* KIAfiA  I auit  \A/niWhnn 


NASA  Lewis  Workshop  - June  4 1998 


■ Voice  is  still  one  of  the  most  important  network  applications  and 
customers  will  not  acdept  GEO  latency  on  voice  calls 

■ GEO  latency  makes  efficient  scheduling  of  Bandwidth-on-Demand 
much  more  difficult 

■ Latency  also  adversely  affects  legacy  protocols  like  DEC  LAT  and 
SNA 

■ By  contrast,  Teledesic's  LEO  Network  will  be  seamlessly 
compatible  with  the  Internet  and  other  terrestrial  networks 
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Components  in  the  Core 
Network 


Service 


NASA  Lewis  Workshop  - June  4 1998 


■ Satellite  Payload 

- Uplink  and  Downlink  Services 

- Table  Driven  QoS  Routing 

- Network  Management 
b UE  - Core  functions 

- Conceptual  Division  in  UE  between 
Core  component  and  Service  Layer 
Component. 

- The  UE  core  element  manages  low- 
level  access  levels  to  the  Teledesic 
Network. 

• Uplink  and  BoD  management 

• Downlink 

• Network  Management 

• Security 


Components  in  Service 
Layer 


NASA  Lewis  Workshop  - Juno  4 1998 


■ UE  - Service  layer  functions 

- Provides  adaptation  of  external  protocols 
for  transport  across  Core  network  and 
initiate  BoD  requests  as  needed. 

a Network  Management 

- Teledesic  Management  System  and 
Constellation  Operation  and  Control 
Center. 

- Teledesic  controlled  services  that  are 
used  to  program  the  Core. 

a Customer 

- Reseller  of  Teledesic  services. 
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Future  Directions 


NASA  Laws  Workshop » Juna  4 1998 

■ Integrated  multi-tiered  Networks 

■ LEOs  essential  part  of  integrated  service  offerings 

- Other  networks  used  in  the  context  of  their  optimal  performance 

B Network  of  Networks 

- Access  independent  of  the  platform 

- Emphasis  on  global  network  management 

a Environment  of  integrated  broadband  network  services. 
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